Баланс між швидкістю транзакцій Solana та створенням вартості

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

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

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

Як виключити токсичні угоди, щоб краще захистити ліквідність?

У поточній системі, оскільки механізм консенсусу Solana використовує періодичні аукціони, то учасники, що беруть участь у торгах, фактично мають пріоритет, що призводить до зловмисної поведінки MEV (мінерська екстракція вартості), яка впливає на справедливість ринку.

Конкретно, у механізмі консенсусу Solana транзакції в межах кожного часового інтервалу (Slot) сортуються за сплаченими пріоритетними Gas витратами, при цьому транзакції з найвищою ставкою виконуються першими. Цей механізм аукціону відбувається кожні 400 мілісекунд. У цьому процесі маркет-мейкери повинні часто коригувати свої ставки, включаючи скасування та повторне розміщення замовлень, щоб відповідати змінам ринкових цін.

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

Для децентралізованих бірж (DEX) зOrder Book ідеальний порядок виконання угод має бути таким: спочатку виконуються всі скасування, потім нові ордери, а вже потім угоди. Проте, механізм консенсусу Solana наразі не може реалізувати це на мікрорівні.

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

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

Отже, Solana потребує механізму, який дозволяє різним протоколам сортувати транзакції відповідно до їхніх потреб. Це концепція, яку Solana постійно підкреслює, звану виконанням під контролем додатка (Application-Controlled Execution, ACE).

Щоб вирішити ці проблеми, Solana запропонувала рішення BAM (ринок складання блоків).

BAM: Нове рішення Solana

BAM побудував шар сортування між прикладним шаром і основною мережею Solana, який також можна назвати шаром попередньої обробки. Він використовує середовища з довіреним виконанням (TEE) для створення приватних пісочниць, у яких транзакції сортуються відповідно до заздалегідь визначених правил або принципу першого прийому – першого обслуговування (FIFO).

Ця інновація спрямована на покращення обслуговування таких протоколів, як книги ордерів, біржі з постійними контрактами та темні ставки.

Порівняння традиційної обробки угод Solana з моделлю BAM

Щоб краще зрозуміти, як BAM будує шар сортування між додатками Solana та основною мережею, ми можемо порівняти традиційний процес транзакцій Solana і процес після впровадження BAM:

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

1. Користувач підтверджує транзакцію у гаманці
2. Транзакція надіслана до RPC вузла
3. RPC надсилає транзакцію до лідера вузла основної мережі Solana поточного періоду
4. Лідер збирає транзакції з пулу транзакцій, сортує їх, упаковує в блок і транслює.
5. Інші вузли голосують

Процес торгівлі після впровадження BAM:

1. Користувач підтверджує транзакцію у гаманці
2. Відправлення транзакції до RPC вузла
3. Транзакції пересилаються до мережі BAM, де відбувається їх сортування в середовищі TEE. Під час цього процесу вузли можуть додавати додаткові транзакції через плагіни (наприклад, оновлення цін оракула), а потім генерувати довідку.
4. Пакет даних про交易 подається до лідера вузла основної мережі Solana
5. Лідер під час збору транзакцій включає пакети даних BAM, упаковує їх в блок та транслює.
6. Інші вузли голосують

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

Режим сортування угод BAM

BAM підтримує три режими роботи:

1. Solana режим за замовчуванням
2. Режим Block-Engine: поточне рішення Jito для MEV, основа якого - механізм аукціону.
3. BAM режим: валідатори строго дотримуються принципу черги (FIFO)

Основні характеристики режиму BAM включають:

1. Довірене середовище виконання (TEEs): використання TEEs для створення середовища конфіденційності для впорядкування транзакцій, забезпечуючи справедливість.

2. Система плагінів: через систему плагінів BAM дозволяє додаткам створювати власну логіку сортування транзакцій. Це користувацьке сортування базується на заздалегідь визначених правилах, а не на випадковому сортуванні вузлів. Система плагінів планує реалізувати складне сортування транзакцій, одночасно зберігаючи гарантії безпеки середовища TEE. Наразі ця система все ще перебуває на ранній стадії розробки.

Реальні застосування BAM

Фактичні застосування BAM включають:

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

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

3. Захист від коливань цін: для DEX виявлення аномально великих ордерів, їх розподіл на дрібні угоди для поетапного виконання, надаючи ринку достатньо часу для реакції, щоб уникнути смертоносної спіралі через безперервні ліквідації чи арбітраж.

4. Захист маркет-мейкерів: У разі виникнення надзвичайних ситуацій можливе виконання скасування ордерів, оновлення цін оракулів, повторне розміщення ордерів маркет-мейкерів протягом мілісекунд, щоб уникнути зловмисного арбітражу та зменшити ціновий розрив.

З впровадженням BAM очікується значне покращення торгового досвіду Solana, що наблизить досвід використання її основної мережі до централізованих бірж.

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