Дорожня карта ICM Solana: «імітаційне шоу» для Hyperliquid?
Нещодавно, велика група лідерів екосистеми Solana зібралася разом, щоб опублікувати технічну дорожню карту під назвою "інтернет-капітальний ринок ( 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. Раніше Drift використовував позасистемну модель угод, і, стикаючись з повністю ланцюговим Hyperliquid, виглядав дещо безсилим. Цього разу, беручи участь у розробці дорожньої карти, очевидно, сподівається використати оновлення на базовому рівні для свого відновлення.
Щоб вирішити основну проблему
Дорожня карта зосереджена на покращенні мікроструктури ринку, простими словами, це означає, що поточний механізм торгівлі в мережі не є достатньо дружнім до маркет-мейкерів, тобто активні учасники торгівлі (Taker) отримують вигоду, а ті, хто виставляє ордери в очікуванні виконання (Market Maker) ( зазнають збитків. Це пов'язано з тим, що Taker, як правило, володіють найновішою інформацією та активно підвищують комісії за транзакції, щоб гарантувати пріоритет виконання своїх угод, тоді як Maker, як правило, не встигають скасувати свої ордери і вимушені виконувати угоди за невигідними цінами.
Деякі високочастотні арбітражники використовують цю асиметрію, щоб розпочати атаку "токсичного трафіку". Наприклад, якщо ціна в ланцюгу ще не оновилася, але ціна поза ланцюгом вже змінилася, арбітражник може купити за старою ціною у маркет-мейкерів, змушуючи їх нести збитки. В результаті Maker, щоб захистити себе, або збільшує спред між купівлею та продажем, або зменшує обсяг ордерів, що призводить до погіршення ліквідності всього ринку.
Дорожня карта ICM має на меті збалансувати цю структуру, щоб залучити високоякісну ліквідність назад на ланцюг.
) Три кроки ICM
Solana розділила цей грандіозний план на три етапи:
короткострокові###1-3 місяці(: основна мета - оптимізувати існуючий досвід торгівлі на ланцюгу, зробити застосунки для книг замовлень більш зручними, зменшити негативний вплив MEV. Конкретні дії включають:
Запуск основної мережі модуля Block Assembly Marketplace)BAM( від Jito Labs. Значення цього модуля полягає в наданні тимчасової зовнішньої системи до запуску Ultimate 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 BAM, щоб хоч якось впоратися і змагатися з Hyperliquid.
Чітко визначивши фон історії, у наступних розділах автор детально проаналізує, які саме фірмові навички ICM імітував та відтворив з Hyperliquid.
Імітація 1: Механізм сортування угод
Проблема: Як вже згадувалося, поточний ланцюг схиляється до того, щоб тягнути за собою учасників, а маркет-мейкери страждають від "отруйного трафіку". Користувачі, які активно беруть ордера, можуть на основі останньої ціни поза ланцюгом миттєво розпочати торгівлю з ордерами, розміщеними в ланцюзі, і отримати пріоритет в угоді, підвищивши комісію, тоді як маркет-мейкери часто не встигають оновити або скасувати ордери. В результаті маркет-мейкери змушені або збільшувати спред, або зовсім знімати ліквідність, що погіршує глибину ринку.
) Остаточне рішення ICM: застосування контрольованого виконання ###ACE(
Дорожня карта ICM пропонує концепцію ACE)Application Controlled Execution(, яка полягає у децентралізації прав на сортування транзакцій для різних застосунків на ланцюгах, де самі застосунки вирішують, як сортувати та виконувати транзакції, пов’язані з цим застосунком. Наприклад, у майбутньому на Solana, яка реалізує ACE, контракти DeFi можуть впровадити такі налаштовані правила сортування транзакцій:
Оновлення цін Oracle: DeFi-додатки можуть перед виконанням великих угод спочатку вставити угоду для отримання останньої ціни від оракула, щоб забезпечити виконання замовлень за останньою розумною ціною, запобігаючи арбітражу на основі застарілих цін, які пропонують маркет-мейкери.
Пріоритет виконання скасування замовлення: Додаток може встановити, що "запит на скасування замовлення" має пріоритет над новими "угодами на купівлю", даючи можливість виробнику вчасно скасувати ордер у разі несприятливої ситуації на ринку.
Аукціон на хвості команди: наприклад, якщо з'являється велика покупка, яка підвищує ціну, DeFi-додаток виставляє на аукціон можливість "слідувати за цим", хто готовий повернути найбільше вигоди протоколу ) або користувачеві (, DeFi-протокол дозволяє виконати угоду того, хто це зробить. DeFi-додаток може повернути доходи від аукціону користувачам, перетворюючи токсичний MEV-трафік на позитивний дохід.
) BAM JITO: перехідний план
Перед офіційним запуском ACE, Jito Labs представила перехідне рішення під назвою Block Assembly Marketplace ###BAM(. Робочий процес BAM є:
Користувач надсилає транзакцію до вузла, що працює на програмному забезпеченні BAM ), а не безпосередньо до поточного лідера (.
BAM вузли збирають локальні транзакції та запускають різноманітні плагіни ) plugin ( для повторного впорядкування пакетів транзакцій ) Bundle ( під захистом конфіденційності. Плагіни працюють у безпечному середовищі TEE, приховуючи вміст транзакцій ззовні перед виконанням ). За допомогою плагінів розробники додатків можуть налаштовувати різні правила впорядкування для своїх контрактів, наприклад, пріоритет скасування замовлень, оновлення цін оракулів перед матчами, або навіть виконання складних аукціонів у додатку тощо.
Відсортований пакет транзакцій знову надсилається лідеру Solana для пакування в блокчейн.
BAM можна вважати випробувальним полем перед запуском ACE на блокчейні, функціонально він дуже близький до остаточного ACE, просто він працює в незалежній мережі поза межами вбудованого протоколу основної ланцюга Solana.
Варто зазначити, що Jito раніше надавала інфраструктуру, орієнтовану на витяг MEV (, таку як Jito Block Engine ), чий бізнес-модель полягала в оптимізації порядку угод для створення можливостей для арбітражників та розподілі прибутку. Це в певному сенсі є "стрілою", яка стоїть на протилежному боці від звичайних користувачів і тих, хто підлягає арбітражу. Проте на початку 2024 року Jito закрила функцію публічного мемпулу (, орієнтовану на арбітражні роботи ), щоб зменшити негативні зовнішні ефекти, такі як сендвіч-атаки. Цей крок свідчить про те, що спільнота 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's ACE/BAM, безумовно, "вчиться" у Hyperliquid. Hyperliquid, як лідер на ринку CLOB, реалізував дружні до маркет-мейкерів механізми за допомогою спеціалізованої ланцюга. Тепер Solana сподівається використати універсальний ланцюг та модульні плагіни, щоб відтворити цей ефект ------ тобто, щоб кожен додаток мав контроль за сортуванням торгівлі, подібно до Hyperliquid.
Імітація два: миттєва фінальність
( Існуючі порівняння консенсусу
Solana наразі використовує Tower BFT, підтвердження та остаточність є ймовірнісними і поступовими: блок отримує 2/3 голосів і вважається "підтвердженим )Confirmed###", але потрібно накопичити приблизно 32 наступних блоки (, що зазвичай займає близько 13 секунд ), щоб бути зафіксованим як "остаточно підтверджений (Finalized)". Для деяких застосувань (, таких як високочастотна торгівля ), кілька секунд часу остаточного підтвердження все ще занадто довго.
HyperBFT є консенсусним алгоритмом, розробленим Hyperliquid, натхненим консенсусом HotStuff, який використовує двократне голосування для підтвердження блоків, забезпечуючи "миттєву остаточність".
Перший раунд: попереднє голосування (Prevote): валідатор, отримавши кандидатський блок, який транслює Пропозер, проводить швидку перевірку. Якщо перевірка пройшла успішно, кожен валідатор проголосує за цей блок однією "попередньою голосом" (Prevote) і транслює його всій мережі. Цей голос представляє: "Я попередньо перевірив, з цим блоком все в порядку."
Другий раунд: попереднє подання ( Precommit ): як тільки якийсь валідатор зібрав від більше двох третин валідаторів Prevote для одного й того ж кандидатного блоку, він отримує достатню впевненість, вважаючи, що більшість мережі
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
5
Поділіться
Прокоментувати
0/400
gas_guzzler
· 08-05 15:39
Списування домашнього завдання також є формою навчання. Що в цьому поганого?
Переглянути оригіналвідповісти на0
RektHunter
· 08-05 15:39
Ну, якщо вже копіювати, то так і бути, sol на цьому і закінчується.
Переглянути оригіналвідповісти на0
PaperHandSister
· 08-05 15:37
Спостерігаючи за виставою, ти списуєш, я списую, всі списують.
Переглянути оригіналвідповісти на0
GweiWatcher
· 08-05 15:28
Дійсно, це просто копіювання, це жахливо!
Переглянути оригіналвідповісти на0
ApeDegen
· 08-05 15:23
Ну, насправді це не зовсім імитація, скоріше запозичення.
Solana ICM дорожня карта націлена на зміни у блоці Hyperliquid у блоці трейдингу.
Дорожня карта ICM Solana: «імітаційне шоу» для Hyperliquid?
Нещодавно, велика група лідерів екосистеми Solana зібралася разом, щоб опублікувати технічну дорожню карту під назвою "інтернет-капітальний ринок ( 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. Раніше Drift використовував позасистемну модель угод, і, стикаючись з повністю ланцюговим Hyperliquid, виглядав дещо безсилим. Цього разу, беручи участь у розробці дорожньої карти, очевидно, сподівається використати оновлення на базовому рівні для свого відновлення.
Щоб вирішити основну проблему
Дорожня карта зосереджена на покращенні мікроструктури ринку, простими словами, це означає, що поточний механізм торгівлі в мережі не є достатньо дружнім до маркет-мейкерів, тобто активні учасники торгівлі (Taker) отримують вигоду, а ті, хто виставляє ордери в очікуванні виконання (Market Maker) ( зазнають збитків. Це пов'язано з тим, що Taker, як правило, володіють найновішою інформацією та активно підвищують комісії за транзакції, щоб гарантувати пріоритет виконання своїх угод, тоді як Maker, як правило, не встигають скасувати свої ордери і вимушені виконувати угоди за невигідними цінами.
Деякі високочастотні арбітражники використовують цю асиметрію, щоб розпочати атаку "токсичного трафіку". Наприклад, якщо ціна в ланцюгу ще не оновилася, але ціна поза ланцюгом вже змінилася, арбітражник може купити за старою ціною у маркет-мейкерів, змушуючи їх нести збитки. В результаті Maker, щоб захистити себе, або збільшує спред між купівлею та продажем, або зменшує обсяг ордерів, що призводить до погіршення ліквідності всього ринку.
Дорожня карта ICM має на меті збалансувати цю структуру, щоб залучити високоякісну ліквідність назад на ланцюг.
) Три кроки ICM
Solana розділила цей грандіозний план на три етапи:
короткострокові###1-3 місяці(: основна мета - оптимізувати існуючий досвід торгівлі на ланцюгу, зробити застосунки для книг замовлень більш зручними, зменшити негативний вплив MEV. Конкретні дії включають:
Запуск основної мережі модуля Block Assembly Marketplace)BAM( від Jito Labs. Значення цього модуля полягає в наданні тимчасової зовнішньої системи до запуску Ultimate 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 BAM, щоб хоч якось впоратися і змагатися з Hyperliquid.
Чітко визначивши фон історії, у наступних розділах автор детально проаналізує, які саме фірмові навички ICM імітував та відтворив з Hyperliquid.
Імітація 1: Механізм сортування угод
Проблема: Як вже згадувалося, поточний ланцюг схиляється до того, щоб тягнути за собою учасників, а маркет-мейкери страждають від "отруйного трафіку". Користувачі, які активно беруть ордера, можуть на основі останньої ціни поза ланцюгом миттєво розпочати торгівлю з ордерами, розміщеними в ланцюзі, і отримати пріоритет в угоді, підвищивши комісію, тоді як маркет-мейкери часто не встигають оновити або скасувати ордери. В результаті маркет-мейкери змушені або збільшувати спред, або зовсім знімати ліквідність, що погіршує глибину ринку.
) Остаточне рішення ICM: застосування контрольованого виконання ###ACE(
Дорожня карта ICM пропонує концепцію ACE)Application Controlled Execution(, яка полягає у децентралізації прав на сортування транзакцій для різних застосунків на ланцюгах, де самі застосунки вирішують, як сортувати та виконувати транзакції, пов’язані з цим застосунком. Наприклад, у майбутньому на Solana, яка реалізує ACE, контракти DeFi можуть впровадити такі налаштовані правила сортування транзакцій:
Оновлення цін Oracle: DeFi-додатки можуть перед виконанням великих угод спочатку вставити угоду для отримання останньої ціни від оракула, щоб забезпечити виконання замовлень за останньою розумною ціною, запобігаючи арбітражу на основі застарілих цін, які пропонують маркет-мейкери.
Пріоритет виконання скасування замовлення: Додаток може встановити, що "запит на скасування замовлення" має пріоритет над новими "угодами на купівлю", даючи можливість виробнику вчасно скасувати ордер у разі несприятливої ситуації на ринку.
Аукціон на хвості команди: наприклад, якщо з'являється велика покупка, яка підвищує ціну, DeFi-додаток виставляє на аукціон можливість "слідувати за цим", хто готовий повернути найбільше вигоди протоколу ) або користувачеві (, DeFi-протокол дозволяє виконати угоду того, хто це зробить. DeFi-додаток може повернути доходи від аукціону користувачам, перетворюючи токсичний MEV-трафік на позитивний дохід.
) BAM JITO: перехідний план
Перед офіційним запуском ACE, Jito Labs представила перехідне рішення під назвою Block Assembly Marketplace ###BAM(. Робочий процес BAM є:
Користувач надсилає транзакцію до вузла, що працює на програмному забезпеченні BAM ), а не безпосередньо до поточного лідера (.
BAM вузли збирають локальні транзакції та запускають різноманітні плагіни ) plugin ( для повторного впорядкування пакетів транзакцій ) Bundle ( під захистом конфіденційності. Плагіни працюють у безпечному середовищі TEE, приховуючи вміст транзакцій ззовні перед виконанням ). За допомогою плагінів розробники додатків можуть налаштовувати різні правила впорядкування для своїх контрактів, наприклад, пріоритет скасування замовлень, оновлення цін оракулів перед матчами, або навіть виконання складних аукціонів у додатку тощо.
Відсортований пакет транзакцій знову надсилається лідеру Solana для пакування в блокчейн.
BAM можна вважати випробувальним полем перед запуском ACE на блокчейні, функціонально він дуже близький до остаточного ACE, просто він працює в незалежній мережі поза межами вбудованого протоколу основної ланцюга Solana.
Варто зазначити, що Jito раніше надавала інфраструктуру, орієнтовану на витяг MEV (, таку як Jito Block Engine ), чий бізнес-модель полягала в оптимізації порядку угод для створення можливостей для арбітражників та розподілі прибутку. Це в певному сенсі є "стрілою", яка стоїть на протилежному боці від звичайних користувачів і тих, хто підлягає арбітражу. Проте на початку 2024 року Jito закрила функцію публічного мемпулу (, орієнтовану на арбітражні роботи ), щоб зменшити негативні зовнішні ефекти, такі як сендвіч-атаки. Цей крок свідчить про те, що спільнота 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's ACE/BAM, безумовно, "вчиться" у Hyperliquid. Hyperliquid, як лідер на ринку CLOB, реалізував дружні до маркет-мейкерів механізми за допомогою спеціалізованої ланцюга. Тепер Solana сподівається використати універсальний ланцюг та модульні плагіни, щоб відтворити цей ефект ------ тобто, щоб кожен додаток мав контроль за сортуванням торгівлі, подібно до Hyperliquid.
Імітація два: миттєва фінальність
( Існуючі порівняння консенсусу
Solana наразі використовує Tower BFT, підтвердження та остаточність є ймовірнісними і поступовими: блок отримує 2/3 голосів і вважається "підтвердженим )Confirmed###", але потрібно накопичити приблизно 32 наступних блоки (, що зазвичай займає близько 13 секунд ), щоб бути зафіксованим як "остаточно підтверджений (Finalized)". Для деяких застосувань (, таких як високочастотна торгівля ), кілька секунд часу остаточного підтвердження все ще занадто довго.
HyperBFT є консенсусним алгоритмом, розробленим Hyperliquid, натхненим консенсусом HotStuff, який використовує двократне голосування для підтвердження блоків, забезпечуючи "миттєву остаточність".
Перший раунд: попереднє голосування (Prevote): валідатор, отримавши кандидатський блок, який транслює Пропозер, проводить швидку перевірку. Якщо перевірка пройшла успішно, кожен валідатор проголосує за цей блок однією "попередньою голосом" (Prevote) і транслює його всій мережі. Цей голос представляє: "Я попередньо перевірив, з цим блоком все в порядку."
Другий раунд: попереднє подання ( Precommit ): як тільки якийсь валідатор зібрав від більше двох третин валідаторів Prevote для одного й того ж кандидатного блоку, він отримує достатню впевненість, вважаючи, що більшість мережі