Швидкість та обсяг交易 Solana: чи дійсно цього достатньо?
Solana відома своєю швидкістю транзакцій та великим обсягом торгів, але чи означає це, що вона досягла досконалості? Коли ми глибше аналізуємо ці транзакції, виникає ключове питання: чи всі ці транзакції створюють реальну цінність?
Насправді, значна частина торгівлі на Solana не походить з реального торгового попиту. Значна частина походить від високочастотних арбітражників, які використовують мілісекундні інформаційні різниці для отримання прибутку. Ці так звані "токсичні трейдери" користуються технологічною перевагою, підвищуючи Gas-кошти, щоб їхні угоди мали пріоритет при пакуванні, коли маркет-мейкери збираються скасувати замовлення, що призводить до збитків для маркет-мейкерів. Щоб компенсувати ці збитки, маркет-мейкери змушені розширювати спред, в результаті чого ці додаткові витрати покривають звичайні користувачі.
Solana завжди мала бачення реалізації order book на ланцюзі для заміни централізованих бірж. Однак, наявність "токсичних трейдерів" стала перешкодою для досягнення цієї мрії. Це виявило нові виклики, з якими стикається Solana: обсяг торгівлі не є еквівалентом ліквідності. Справжній здоровий ринок потребує не більше угод, а угод вищої якості.
Як виключити токсичні угоди, щоб краще захистити ліквідність?
У поточній системі, через те, що механізм консенсусу Solana використовує періодичні аукціони, ті, хто приймає замовлення, фактично мають пріоритет, що призводить до впливу зловмисної MEV (максимально можливе отримання вартості) на справедливість ринку.
Конкретно, у механізмі консенсусу Solana кожні 400 мілісекунд (Slot) транзакції сортуються за сплаченими пріоритетними Gas-витратами, причому транзакції з найвищими ставками виконуються першими. У такому механізмі маркет-мейкерам потрібно часто коригувати свої котирування, постійно скасовуючи та знову розміщуючи замовлення, щоб відповідати змінам ринкової ціни.
А високочастотні арбітражники моніторять цінові відмінності і, як тільки знаходять можливість, одразу виконують угоду. Вони можуть платити вищі збори, щоб забезпечити виконання своїх угод до того, як маркет-мейкери скасують замовлення, що призводить до частих втрат для маркет-мейкерів.
Для децентралізованих бірж (DEX) зorder book ідеальним порядком торгівлі має бути: з коливаннями ціни спочатку виконуються всі операції скасування, далі нові ордери, а в останню чергу – угоди. Однак поточний механізм консенсусу Solana не може реалізувати це на мікрорівні.
Те ж саме стосується котирувань оркестраторів: ідеальною ситуацією було б спочатку оновити ціну оркестратора, а потім виконати угоди, які залежать від цієї ціни. Але в межах поточних 400 мілісекунд ринок може через різкі коливання призвести до того, що угоди все ще виконуються за початковою ціною.
Для кредитних угод найкращою практикою є спочатку поповнити заставу, а потім проводити ліквідацію.
Тому ідеальним рішенням має бути дозволити різним протоколам упорядковувати транзакції відповідно до їхніх потреб, що є концепцією Application-Controlled Execution (ACE), на якій наголошує Solana.
Щоб впоратися з цими викликами, Solana запропонувала рішення BAM (ринок складання блоків).
Ринок збору блоків: нова відповідь Solana
BAM побудував шар сортування, або так званий шар попередньої обробки, між прикладним рівнем та основною мережею Solana. Він використовує надійне середовище виконання (TEE) для створення приватного пісочниці, де транзакції сортуються відповідно до заздалегідь визначених правил або принципу «перший прийшов – перший обслужений» (FIFO).
Ця інновація має на меті краще обслуговувати такі протоколи, як книги замовлень, біржі безстрокових контрактів та темні пулл.
Як BAM змінює торговий процес Solana?
У традиційному процесі торгівлі Solana, після підтвердження угоди користувачем, угода надсилається до лідера вузла поточного слоту через RPC-вузол, лідер збирає угоди з пули угод, сортує їх і пакує в блок для трансляції, а врешті-решт інші вузли голосують для підтвердження.
А в застосунках з підключенням до BAM процес交易 трохи відрізняється:
Користувач підтверджує угоду
Торгівля надіслана до RPC-вузла
Перехід транзакції в мережу BAM, сортування у середовищі TEE
Відсортовані пакети транзакцій подаються до лідера вузла основної мережі Solana
Лідер включає пакет даних BAM до блоку та транслює його
Інші вузли голосують для підтвердження
Слід зазначити, що BAM не конфліктує з процесом консенсусу основної мережі Solana, а є необов'язковою функцією. Він попередньо виконує сортування транзакцій за допомогою "позамережевого" методу, а потім подає упорядковані пакети транзакцій до основної мережі Solana.
Режим роботи BAM
BAM підтримує три режими роботи:
Режим за замовчуванням Solana
Режим Block-Engine (сучасне рішення MEV від Jito, основа якого лежить у механізмі аукціону)
BAM-режим (валідатори суворо за порядком FIFO)
Основні характеристики режиму BAM включають:
Використання середовища довіреного виконання (TEE) для створення приватного середовища, що забезпечує справедливість порядку транзакцій.
Дозволити додаткам створювати власну логіку сортування транзакцій через систему плагінів, щоб реалізувати складні вимоги до сортування.
Реальне застосування BAM
Застосування BAM є широким, ось кілька конкретних прикладів:
Захист ліквідації кредитів: пріоритетно виконуються операції з додатковим забезпеченням, а потім проводиться перевірка ліквідації.
Атомарні торгові комбінації: спочатку оновити ціну оракула, а потім виконати угоди, які залежать від цієї ціни; для контрактних DEX також можна одночасно розрахувати відповідні похідні.
Захист від коливань цін: виявлення аномально великих заявок та їх розподіл на дрібні угоди для поетапного виконання, щоб дати ринку час на реагування.
Захист маркет-мейкерів: під час надзвичайних ситуацій дозволяє скасування замовлень, оновлення цін оракула та повторне розміщення замовлень за мілісекунди, щоб уникнути злочинного арбітражу.
Розгортання BAM суттєво покращить торговий досвід Solana, наблизивши його до досвіду централізованих бірж у застосунках основної мережі.
У загальному підсумку, BAM надає Solana можливість верифікації, захисту приватності та програмованості в процесі обробки транзакцій. Це дозволяє розробникам створювати центральні обмежені книги замовлень, біржі постійних контрактів, темні басейни та інші фінансові інфраструктури, які потребують точного контролю за порядком, детермінованого виконання та захисту приватності, що сприяє інноваційному розвитку екосистеми Solana.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
4
Поділіться
Прокоментувати
0/400
HappyToBeDumped
· 14год тому
solмої невдахи обдурювали людей, як лохів
Переглянути оригіналвідповісти на0
SingleForYears
· 14год тому
Звичайні користувачі несуть витрати? Обман для дурнів.
Переглянути оригіналвідповісти на0
ruggedNotShrugged
· 14год тому
Помийся та лягай спати, обдурювати людей, як лохів, взявся за справу.
Solana представила рішення BAM для підвищення якості та справедливості транзакцій
Швидкість та обсяг交易 Solana: чи дійсно цього достатньо?
Solana відома своєю швидкістю транзакцій та великим обсягом торгів, але чи означає це, що вона досягла досконалості? Коли ми глибше аналізуємо ці транзакції, виникає ключове питання: чи всі ці транзакції створюють реальну цінність?
Насправді, значна частина торгівлі на Solana не походить з реального торгового попиту. Значна частина походить від високочастотних арбітражників, які використовують мілісекундні інформаційні різниці для отримання прибутку. Ці так звані "токсичні трейдери" користуються технологічною перевагою, підвищуючи Gas-кошти, щоб їхні угоди мали пріоритет при пакуванні, коли маркет-мейкери збираються скасувати замовлення, що призводить до збитків для маркет-мейкерів. Щоб компенсувати ці збитки, маркет-мейкери змушені розширювати спред, в результаті чого ці додаткові витрати покривають звичайні користувачі.
Solana завжди мала бачення реалізації order book на ланцюзі для заміни централізованих бірж. Однак, наявність "токсичних трейдерів" стала перешкодою для досягнення цієї мрії. Це виявило нові виклики, з якими стикається Solana: обсяг торгівлі не є еквівалентом ліквідності. Справжній здоровий ринок потребує не більше угод, а угод вищої якості.
Як виключити токсичні угоди, щоб краще захистити ліквідність?
У поточній системі, через те, що механізм консенсусу Solana використовує періодичні аукціони, ті, хто приймає замовлення, фактично мають пріоритет, що призводить до впливу зловмисної MEV (максимально можливе отримання вартості) на справедливість ринку.
Конкретно, у механізмі консенсусу Solana кожні 400 мілісекунд (Slot) транзакції сортуються за сплаченими пріоритетними Gas-витратами, причому транзакції з найвищими ставками виконуються першими. У такому механізмі маркет-мейкерам потрібно часто коригувати свої котирування, постійно скасовуючи та знову розміщуючи замовлення, щоб відповідати змінам ринкової ціни.
А високочастотні арбітражники моніторять цінові відмінності і, як тільки знаходять можливість, одразу виконують угоду. Вони можуть платити вищі збори, щоб забезпечити виконання своїх угод до того, як маркет-мейкери скасують замовлення, що призводить до частих втрат для маркет-мейкерів.
Для децентралізованих бірж (DEX) зorder book ідеальним порядком торгівлі має бути: з коливаннями ціни спочатку виконуються всі операції скасування, далі нові ордери, а в останню чергу – угоди. Однак поточний механізм консенсусу Solana не може реалізувати це на мікрорівні.
Те ж саме стосується котирувань оркестраторів: ідеальною ситуацією було б спочатку оновити ціну оркестратора, а потім виконати угоди, які залежать від цієї ціни. Але в межах поточних 400 мілісекунд ринок може через різкі коливання призвести до того, що угоди все ще виконуються за початковою ціною.
Для кредитних угод найкращою практикою є спочатку поповнити заставу, а потім проводити ліквідацію.
Тому ідеальним рішенням має бути дозволити різним протоколам упорядковувати транзакції відповідно до їхніх потреб, що є концепцією Application-Controlled Execution (ACE), на якій наголошує Solana.
Щоб впоратися з цими викликами, Solana запропонувала рішення BAM (ринок складання блоків).
Ринок збору блоків: нова відповідь Solana
BAM побудував шар сортування, або так званий шар попередньої обробки, між прикладним рівнем та основною мережею Solana. Він використовує надійне середовище виконання (TEE) для створення приватного пісочниці, де транзакції сортуються відповідно до заздалегідь визначених правил або принципу «перший прийшов – перший обслужений» (FIFO).
Ця інновація має на меті краще обслуговувати такі протоколи, як книги замовлень, біржі безстрокових контрактів та темні пулл.
Як BAM змінює торговий процес Solana?
У традиційному процесі торгівлі Solana, після підтвердження угоди користувачем, угода надсилається до лідера вузла поточного слоту через RPC-вузол, лідер збирає угоди з пули угод, сортує їх і пакує в блок для трансляції, а врешті-решт інші вузли голосують для підтвердження.
А в застосунках з підключенням до BAM процес交易 трохи відрізняється:
Слід зазначити, що BAM не конфліктує з процесом консенсусу основної мережі Solana, а є необов'язковою функцією. Він попередньо виконує сортування транзакцій за допомогою "позамережевого" методу, а потім подає упорядковані пакети транзакцій до основної мережі Solana.
Режим роботи BAM
BAM підтримує три режими роботи:
Основні характеристики режиму BAM включають:
Реальне застосування BAM
Застосування BAM є широким, ось кілька конкретних прикладів:
Розгортання BAM суттєво покращить торговий досвід Solana, наблизивши його до досвіду централізованих бірж у застосунках основної мережі.
У загальному підсумку, BAM надає Solana можливість верифікації, захисту приватності та програмованості в процесі обробки транзакцій. Це дозволяє розробникам створювати центральні обмежені книги замовлень, біржі постійних контрактів, темні басейни та інші фінансові інфраструктури, які потребують точного контролю за порядком, детермінованого виконання та захисту приватності, що сприяє інноваційному розвитку екосистеми Solana.