Solana вже достатньо швидка, об'єм достатньо великий. Тоді це дійсно "достатньо"?
Коли ми розглядаємо ті угоди, постає питання: чи справді ці угоди створюють цінність?
Великі об'єми торгів Solana не походять з реального попиту на торгівлю, а є результатом високочастотних арбітражників, які використовують мілісекундні інформаційні розриви для отримання прибутку. Ці "токсичні трейдери" (Toxic-takers) використовують технологічні переваги, щоб збільшити Gas, коли маркет-мейкери (Maker) збираються скасувати ордер, щоб їхня угода потрапила в першу чергу в пакет, завершуючи арбітраж та завдаючи збитків маркет-мейкерам. Щоб компенсувати збитки, маркет-мейкери змушені розширювати спред.
Врешті-решт, звичайні користувачі за це платять. Solana завжди мала мрію реалізувати книгу замовлень в ланцюзі, замінивши CEX. Але в такому випадку, "токсичні трейдери" стають перешкодою для втілення мрії. Ось новий виклик, з яким стикається Solana: об'єм ≠ ліквідність. Справжньому здоровому ринку потрібні не більше угод, а кращі угоди.
Як можна виключити токсичні交易, щоб краще захистити ліквідність?
У поточній системі, особи, що приймають угоди (Takers), завдяки періодичному аукціонному механізму консенсусу Solana, мають фактичну перевагу, що впливає на справедливість ринку через зловмисний MEV.
Як зрозуміти?
У поточному консенсусі Solana, у кожному часовому слоті, транзакції сортуються за сплаченими пріоритетними витратами на газ; хто запропонує вищу ціну, той отримає перше виконання транзакції. Ця аукціонна система є періодичною, кожні 400 мілісекунд відбувається новий слот.
У цьому процесі маркет-мейкери повинні часто коригувати ціни, скасовувати замовлення та повторно їх виставляти. При зміні ринкової ціни необхідно терміново оновлювати.
А ті, хто купує (Taker), особливо високочастотні арбітражники, моніторять різницю в цінах і, помітивши можливість, одразу ж укладають угоду. Отже, арбітражники можуть укладати угоди, сплачуючи вищі комісії, щоб випередити скасування замовлення. Це призводить до того, що маркетмейкери часто стають "мішенню", зазнаючи збитків.
Для книги замовлень DEX ідеальним порядком повинно бути: спочатку виконати всі скасування, потім виконати нові ордери, а наостанок виконати угоди, як ціна коливається. Це те, чого наразі консенсус Solana не може досягти на мікрорівні.
А на рівні котирувань оракула ситуація така ж: у ідеальному випадку спочатку оновлюється ціна оракула, а потім виконуються угоди, що залежать від цієї ціни. Але в умовах поточного інтервалу в 400 мілісекунд ринок може зазнати різких коливань, що призведе до виконання угод за первісною ціною.
Для кредитних угод краще спочатку внести заставу, а потім здійснити ліквідацію.
Отже, було б добре мати спосіб, який дозволяє різним протоколам сортувати угоди за потребою, а саме ACE (Application-Controlled Execution), на що постійно акцентує увагу Solana.
BAM (Block Assembly Marketplace, ринок збору блоків) саме є відповіддю Solana.
BAM на Solana ланцюзі між додатком та основною мережею побудував шар сортування, або як його ще називають, шар попередньої обробки.
Використання надійних середовищ виконання (Trusted Execution Environments, TEEs) для створення приватного пісочниці, де в межах пісочниці за заздалегідь визначеними правилами сортування або FIFO (перший прийшов - перший вийшов) здійснюється сортування транзакцій.
краще обслуговувати книги замовлень (CLOBs), біржі безстрокових контрактів (Perpetual Exchanges), протоколи темних пулів (Dark Pools).
Solana зазвичай упаковує угоди в порівнянні з режимом BAM
Як зрозуміти, що BAM побудував шар сортування між застосунком Solana та основною мережею? Спочатку давайте зробимо інтуїтивне порівняння.
Нормальний процес торгівлі Solana,
1）Користувач підтверджує транзакцію у гаманці,
2）об'єм надіслано до RPC вузла，
RPC надсилає лідеру ноди Solana основної мережі під час поточного слот-періоду,
4）Лідер збирає транзакції з пулу, сортує їх, пакує в блоки та транслює,
Голосування інших вузлів.
Якщо певний додаток підключає BAM, процес交易 виглядає так,
Користувач підтверджує транзакцію у гаманці,
2）відправка транзакції на RPC вузол,
3）Транзакції передаються в мережу BAM, де вони сортуються в TEE-приватності. Протягом цього процесу вузли можуть додавати додаткові транзакції через плагіни, наприклад, оновлення цін оракулів, а потім генерувати докази,
Об'єм даних транзакції подано до лідер-ноуту основної мережі Solana,
5）Лідер, збираючи транзакції, отримує пакети даних BAM, а потім упаковує їх у блоки для трансляції,
Голосування решти вузлів.
Отже, насправді BAM не суперечить поточному процесу консенсусу в мережі Solana, а є своєрідною "опцією". BAM не працює безпосередньо в мережі Solana, а виконує попередню сортировку транзакцій у так званому "позасистемному" режимі, упаковує транзакції і потім подає їх до мережі Solana.
BAM об'єм сортування
BAM підтримує три режими роботи,
1）Режим за замовчуванням Solana；
2）Block-Engine режим; поточне рішення Jito з MEV, основа якого - механізм аукціону.
BAM режим, валідатори строго дотримуються FIFO (перший прийшов - перший вийшов) порядку.
Основні моменти моделі BAM такі:
Достовірне виконання середовища TEEs: приватність та справедливість Використовуючи достовірне виконання середовища TEEs, створюємо приватне середовище для впорядкування транзакцій. Інша сторона приватності називається справедливістю.
2）Плагінова система Plugin: складне сортування За допомогою плагінової системи BAM дозволяє додаткам створювати власну логіку сортування транзакцій. І це власне сортування не означає, що вузли можуть сортувати так, як їм хочеться, а відбувається відповідно до заздалегідь визначених правил.
План плагіна реалізує складне сортування угод, при цьому зберігаючи безпеку середовища TEE. Наразі він перебуває на ранніх стадіях розробки.
Як згадувалося раніше,
Для книги замовлень DEX ідеальним порядком виконання повинно бути: спочатку виконати всі скасування, потім нові ордери, і нарешті, угоди, у міру коливань цін. Це те, чого наразі не може досягти консенсус Solana на мікрорівні.
А на рівні котирувань оріаклів ситуація така ж, ідеальний варіант полягає в тому, щоб спочатку оновити ціну оріакла, а потім виконати угоди, які залежать від цієї ціни. Але в даний час, протягом 400 мілісекундного інтервалу, котирування можуть змінюватися через різкі коливання, що призводить до того, що угода все ще виконується за початковою ціною.
Для кредитних угод найкраще спочатку внести заставу, а потім провести ліквідацію. Це фактично реалізує функцію контролю виконання додатку ACE.
Тож, що насправді реалізував BAM?
Наприклад,
Захист ліквідації позик
Для кредитних угод, після виявлення ризику ліквідації, спочатку виконується операція з додатковими забезпеченнями, а потім проводиться перевірка ліквідації.
Атомарні комбінації угод
Для DEX спочатку оновлюється ціна оракула, після чого виконується торгівля, що залежить від ціни. Якщо це контрактний DEX, також можуть бути розраховані відповідні похідні. Всі вищезазначені операції виконуються в один і той же часовий інтервал.
3）Захист від коливань цін
Для DEX, виявлення аномально великих замовлень, розподіл великих замовлень на менші частини, виконання партіями, надання часу для реакції ринку, уникнення послідовного ліквідації або арбітражу, що викликають смертельну спіраль.
Захист маркет-мейкерів
Сталася надзвичайна ситуація, скасування замовлення за мілісекунди, oracle оновлює ціну, маркет-мейкери повторно розміщують замовлення. Уникнути злого арбітражу, зменшити різницю в ціні.
BAM спочатку планувався до випуску в кінці липня.
І, з впровадженням BAM, досвід торгівлі на Solana значно покращиться. BAM зробить досвід використання додатків на основній мережі Solana більш схожим на CEX.
Отже,
BAM приніс до процесу обробки транзакцій Solana верифікацію, захист приватності та програмованість, що дозволяє розробникам створювати центральні обмежені книги ордерів (CLOBs), біржі з постійними контрактами (Perpetual Exchanges), темні басейни (Dark Pools) та іншу фінансову інфраструктуру, яка потребує контролю за сортуванням, детермінованого виконання та захисту приватності, сприяючи інноваційному розвитку екосистеми Solana.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Розшифровка ринку збору блоків Solana BAM: коли швидкість більше не є єдиною метою
Solana вже достатньо швидка, об'єм достатньо великий. Тоді це дійсно "достатньо"?
Коли ми розглядаємо ті угоди, постає питання: чи справді ці угоди створюють цінність?
Великі об'єми торгів Solana не походять з реального попиту на торгівлю, а є результатом високочастотних арбітражників, які використовують мілісекундні інформаційні розриви для отримання прибутку. Ці "токсичні трейдери" (Toxic-takers) використовують технологічні переваги, щоб збільшити Gas, коли маркет-мейкери (Maker) збираються скасувати ордер, щоб їхня угода потрапила в першу чергу в пакет, завершуючи арбітраж та завдаючи збитків маркет-мейкерам. Щоб компенсувати збитки, маркет-мейкери змушені розширювати спред.
Врешті-решт, звичайні користувачі за це платять. Solana завжди мала мрію реалізувати книгу замовлень в ланцюзі, замінивши CEX. Але в такому випадку, "токсичні трейдери" стають перешкодою для втілення мрії. Ось новий виклик, з яким стикається Solana: об'єм ≠ ліквідність. Справжньому здоровому ринку потрібні не більше угод, а кращі угоди.
Як можна виключити токсичні交易, щоб краще захистити ліквідність?
У поточній системі, особи, що приймають угоди (Takers), завдяки періодичному аукціонному механізму консенсусу Solana, мають фактичну перевагу, що впливає на справедливість ринку через зловмисний MEV.
Як зрозуміти?
У поточному консенсусі Solana, у кожному часовому слоті, транзакції сортуються за сплаченими пріоритетними витратами на газ; хто запропонує вищу ціну, той отримає перше виконання транзакції. Ця аукціонна система є періодичною, кожні 400 мілісекунд відбувається новий слот.
У цьому процесі маркет-мейкери повинні часто коригувати ціни, скасовувати замовлення та повторно їх виставляти. При зміні ринкової ціни необхідно терміново оновлювати.
А ті, хто купує (Taker), особливо високочастотні арбітражники, моніторять різницю в цінах і, помітивши можливість, одразу ж укладають угоду. Отже, арбітражники можуть укладати угоди, сплачуючи вищі комісії, щоб випередити скасування замовлення. Це призводить до того, що маркетмейкери часто стають "мішенню", зазнаючи збитків.
Для книги замовлень DEX ідеальним порядком повинно бути: спочатку виконати всі скасування, потім виконати нові ордери, а наостанок виконати угоди, як ціна коливається. Це те, чого наразі консенсус Solana не може досягти на мікрорівні.
А на рівні котирувань оракула ситуація така ж: у ідеальному випадку спочатку оновлюється ціна оракула, а потім виконуються угоди, що залежать від цієї ціни. Але в умовах поточного інтервалу в 400 мілісекунд ринок може зазнати різких коливань, що призведе до виконання угод за первісною ціною.
Для кредитних угод краще спочатку внести заставу, а потім здійснити ліквідацію.
Отже, було б добре мати спосіб, який дозволяє різним протоколам сортувати угоди за потребою, а саме ACE (Application-Controlled Execution), на що постійно акцентує увагу Solana.
BAM (Block Assembly Marketplace, ринок збору блоків) саме є відповіддю Solana.
BAM на Solana ланцюзі між додатком та основною мережею побудував шар сортування, або як його ще називають, шар попередньої обробки.
Використання надійних середовищ виконання (Trusted Execution Environments, TEEs) для створення приватного пісочниці, де в межах пісочниці за заздалегідь визначеними правилами сортування або FIFO (перший прийшов - перший вийшов) здійснюється сортування транзакцій.
краще обслуговувати книги замовлень (CLOBs), біржі безстрокових контрактів (Perpetual Exchanges), протоколи темних пулів (Dark Pools).
Solana зазвичай упаковує угоди в порівнянні з режимом BAM
Як зрозуміти, що BAM побудував шар сортування між застосунком Solana та основною мережею? Спочатку давайте зробимо інтуїтивне порівняння.
Нормальний процес торгівлі Solana,
1）Користувач підтверджує транзакцію у гаманці,
2）об'єм надіслано до RPC вузла，
4）Лідер збирає транзакції з пулу, сортує їх, пакує в блоки та транслює,
Якщо певний додаток підключає BAM, процес交易 виглядає так,
2）відправка транзакції на RPC вузол,
3）Транзакції передаються в мережу BAM, де вони сортуються в TEE-приватності. Протягом цього процесу вузли можуть додавати додаткові транзакції через плагіни, наприклад, оновлення цін оракулів, а потім генерувати докази,
5）Лідер, збираючи транзакції, отримує пакети даних BAM, а потім упаковує їх у блоки для трансляції,
Отже, насправді BAM не суперечить поточному процесу консенсусу в мережі Solana, а є своєрідною "опцією". BAM не працює безпосередньо в мережі Solana, а виконує попередню сортировку транзакцій у так званому "позасистемному" режимі, упаковує транзакції і потім подає їх до мережі Solana.
BAM об'єм сортування
BAM підтримує три режими роботи,
1）Режим за замовчуванням Solana；
2）Block-Engine режим; поточне рішення Jito з MEV, основа якого - механізм аукціону.
Основні моменти моделі BAM такі:
2）Плагінова система Plugin: складне сортування За допомогою плагінової системи BAM дозволяє додаткам створювати власну логіку сортування транзакцій. І це власне сортування не означає, що вузли можуть сортувати так, як їм хочеться, а відбувається відповідно до заздалегідь визначених правил.
План плагіна реалізує складне сортування угод, при цьому зберігаючи безпеку середовища TEE. Наразі він перебуває на ранніх стадіях розробки.
Як згадувалося раніше,
Для книги замовлень DEX ідеальним порядком виконання повинно бути: спочатку виконати всі скасування, потім нові ордери, і нарешті, угоди, у міру коливань цін. Це те, чого наразі не може досягти консенсус Solana на мікрорівні.
А на рівні котирувань оріаклів ситуація така ж, ідеальний варіант полягає в тому, щоб спочатку оновити ціну оріакла, а потім виконати угоди, які залежать від цієї ціни. Але в даний час, протягом 400 мілісекундного інтервалу, котирування можуть змінюватися через різкі коливання, що призводить до того, що угода все ще виконується за початковою ціною.
Для кредитних угод найкраще спочатку внести заставу, а потім провести ліквідацію. Це фактично реалізує функцію контролю виконання додатку ACE.
Тож, що насправді реалізував BAM?
Наприклад,
Для кредитних угод, після виявлення ризику ліквідації, спочатку виконується операція з додатковими забезпеченнями, а потім проводиться перевірка ліквідації.
Для DEX спочатку оновлюється ціна оракула, після чого виконується торгівля, що залежить від ціни. Якщо це контрактний DEX, також можуть бути розраховані відповідні похідні. Всі вищезазначені операції виконуються в один і той же часовий інтервал.
3）Захист від коливань цін
Для DEX, виявлення аномально великих замовлень, розподіл великих замовлень на менші частини, виконання партіями, надання часу для реакції ринку, уникнення послідовного ліквідації або арбітражу, що викликають смертельну спіраль.
Сталася надзвичайна ситуація, скасування замовлення за мілісекунди, oracle оновлює ціну, маркет-мейкери повторно розміщують замовлення. Уникнути злого арбітражу, зменшити різницю в ціні.
BAM спочатку планувався до випуску в кінці липня.
І, з впровадженням BAM, досвід торгівлі на Solana значно покращиться. BAM зробить досвід використання додатків на основній мережі Solana більш схожим на CEX.
Отже,
BAM приніс до процесу обробки транзакцій Solana верифікацію, захист приватності та програмованість, що дозволяє розробникам створювати центральні обмежені книги ордерів (CLOBs), біржі з постійними контрактами (Perpetual Exchanges), темні басейни (Dark Pools) та іншу фінансову інфраструктуру, яка потребує контролю за сортуванням, детермінованого виконання та захисту приватності, сприяючи інноваційному розвитку екосистеми Solana.
Вищезазначене.