Від "цінової кривої" AMM до "купівельних і продажних котирувань" на книжці замовлень, це не просто зміна інтерфейсу користувача, а ключовий крок у еволюції DEX від "раю для роздрібних інвесторів" до "професійного торгового ринку". Книжка замовлень, з її точністю у встановленні цін та максимальною ефективністю капіталу, загалом вважається майбутнім DEX.
Проте жорстока реальність полягає в тому, що майже всі основні DEX з ордерними книгами зіткнулися з невидимою "стіною" у своїх технічних реалізаціях. Щоб "децентралізувати" ордерну книгу, яка є природно централізованим продуктом, їм доводиться робити болісний вибір між продуктивністю, витратами та безпекою.
Щоб зрозуміти майбутнє DEX, ми спочатку повинні детально розглянути основні реалізації та технологічні обмеження, з якими вони стикаються.
Шлях перший: "Смерть продуктивності" чистої ланцюгової книги замовлень
Типові представники: ранній Serum (на базі Solana) та деякі нативні DEX на L2.
Спосіб реалізації: Вся логіка зберігання, розміщення ордерів, скасування, злиття тощо всього order book виконується в смарт-контракті на блокчейні.
Технічні обмеження:
Потолок продуктивності: це найфатальніший вузький канал. Незалежно від того, наскільки високий TPS базового блокчейну, він не може задовольнити вимоги високочастотної торгівлі до "мілісекундних" операцій з книгами замовлень. Кожна взаємодія вимагає очікування підтвердження блоку, що в професійній торгівлі є неприпустимим.
Високі витрати: Кожен раз, коли ви ставите або скасовуєте замовлення, потрібно сплачувати газовий збір. Це є астрономічними витратами для маркет-мейкерів і високочастотних трейдерів, які потребують частих коригувань цін, що в основному стримує постачання ліквідності.
MEV зони катастрофи: Всі замовлення публічно доступні в пам'яті пулу (Mempool), створюючи ідеальне полювання для MEV-роботів для атаки на випередження та сендвіч-атаки.
Шлях два: "Проблеми безпеки" книги замовлень прикладного ланцюга
Типові представники: dYdX v4, Hyperliquid
Спосіб реалізації: Щоб повністю позбутися обмежень продуктивності публічних блокчейнів, ми з нуля побудуємо незалежний додаток-ланцюг (Appchain), створений для транзакцій.
Технологічні обмеження:
Зменшення вимірності моделі безпеки: це її основний компроміс. Її безпека, що забезпечується "спільною безпекою" такими публічними блокчейнами, як Ethereum, зменшується до "суверенної безпеки", що забезпечується її власною мережею валідаторів. Це означає, що верхня межа її безпеки обмежена ринковою вартістю її власного токена та ступенем децентралізації валідаторів, що створює "стелю довіри".
Екологічна ізоляція: Розрив з основною екосистемою призводить до того, що її комбінованість практично дорівнює нулю, а вхід і вихід активів сильно залежать від безпеки міжланцюгових мостів.
"Змішана архітектура": геніальне деконструювання та реорганізація
Коли обидва вищезазначені шляхи потрапляють у свої «мертві кінці», з'являється третій, більш елегантний і логічний шлях. Це «гібридна архітектура», представлена QuBitDEX.
Це не компроміс, а глибока деконструкція та реорганізація дії "торгівлі", основана на перших принципах. Це ставить найосновніше питання: які етапи в процесі торгівлі повинні бути гарантовані блокчейном, а які – ні?
Відповідь:
"Процес" прагне до ефективності: подача, відповідність та оновлення замовлень — це високочастотний, швидкоплинний процес. Цей процес прагне до максимальної ефективності. Тому він розміщений у потужному поза-ланцюговому механізмі зведення. Це, в основному, вирішує "біль продуктивності" та "біль витрат".
"Результат" прагне безпеки: остаточне врегулювання угоди та передача активів є низькочастотним процесом, але необхідно гарантувати абсолютну безпеку та незмінність результату. Цей результат прагне до крайньої безпеки та остаточності. Тому він закріплюється на найбезпечнішому рівні розрахунків за допомогою технологій, таких як ZK-Rollup. Це в корені вирішує "проблему безпеки".
Суть «змішаної архітектури» полягає в ідеальному «професійній спеціалізації». Вона повертає блокчейн до того, що він робить найкраще і що він повинен робити — стати децентралізованим, ненадійним «кінцевим розрахунковим рівнем» та «судом фактів», а не незграбним «універсальним сервером», що намагається вирішити все.
Це вже не просто черговий технічний ітераційний процес. Це стрибок у мисленні. Він дає нам зрозуміти, що майбутнє DEX не полягає в тому, щоб "потужно" витримувати вимоги до продуктивності книг замовлень за допомогою більш потужних ланцюгів, а в тому, щоб "розкласти" вимоги до книг замовлень за допомогою більш розумної архітектури.
А це, можливо, є остаточною відповіддю на запитання, яке ми можемо передбачити, щодо DEX на основі книги ордерів.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Глибина розбору технічних обмежень основних DEX з ордерними книгами: чому "гібридна архітектура" може бути остаточною відповіддю?
Автор: Alex
Від "цінової кривої" AMM до "купівельних і продажних котирувань" на книжці замовлень, це не просто зміна інтерфейсу користувача, а ключовий крок у еволюції DEX від "раю для роздрібних інвесторів" до "професійного торгового ринку". Книжка замовлень, з її точністю у встановленні цін та максимальною ефективністю капіталу, загалом вважається майбутнім DEX.
Проте жорстока реальність полягає в тому, що майже всі основні DEX з ордерними книгами зіткнулися з невидимою "стіною" у своїх технічних реалізаціях. Щоб "децентралізувати" ордерну книгу, яка є природно централізованим продуктом, їм доводиться робити болісний вибір між продуктивністю, витратами та безпекою.
Щоб зрозуміти майбутнє DEX, ми спочатку повинні детально розглянути основні реалізації та технологічні обмеження, з якими вони стикаються.
Шлях перший: "Смерть продуктивності" чистої ланцюгової книги замовлень
Типові представники: ранній Serum (на базі Solana) та деякі нативні DEX на L2.
Спосіб реалізації: Вся логіка зберігання, розміщення ордерів, скасування, злиття тощо всього order book виконується в смарт-контракті на блокчейні.
Технічні обмеження:
Потолок продуктивності: це найфатальніший вузький канал. Незалежно від того, наскільки високий TPS базового блокчейну, він не може задовольнити вимоги високочастотної торгівлі до "мілісекундних" операцій з книгами замовлень. Кожна взаємодія вимагає очікування підтвердження блоку, що в професійній торгівлі є неприпустимим.
Високі витрати: Кожен раз, коли ви ставите або скасовуєте замовлення, потрібно сплачувати газовий збір. Це є астрономічними витратами для маркет-мейкерів і високочастотних трейдерів, які потребують частих коригувань цін, що в основному стримує постачання ліквідності.
MEV зони катастрофи: Всі замовлення публічно доступні в пам'яті пулу (Mempool), створюючи ідеальне полювання для MEV-роботів для атаки на випередження та сендвіч-атаки.
Шлях два: "Проблеми безпеки" книги замовлень прикладного ланцюга
Типові представники: dYdX v4, Hyperliquid
Спосіб реалізації: Щоб повністю позбутися обмежень продуктивності публічних блокчейнів, ми з нуля побудуємо незалежний додаток-ланцюг (Appchain), створений для транзакцій.
Технологічні обмеження:
Зменшення вимірності моделі безпеки: це її основний компроміс. Її безпека, що забезпечується "спільною безпекою" такими публічними блокчейнами, як Ethereum, зменшується до "суверенної безпеки", що забезпечується її власною мережею валідаторів. Це означає, що верхня межа її безпеки обмежена ринковою вартістю її власного токена та ступенем децентралізації валідаторів, що створює "стелю довіри".
Екологічна ізоляція: Розрив з основною екосистемою призводить до того, що її комбінованість практично дорівнює нулю, а вхід і вихід активів сильно залежать від безпеки міжланцюгових мостів.
"Змішана архітектура": геніальне деконструювання та реорганізація
Коли обидва вищезазначені шляхи потрапляють у свої «мертві кінці», з'являється третій, більш елегантний і логічний шлях. Це «гібридна архітектура», представлена QuBitDEX.
Це не компроміс, а глибока деконструкція та реорганізація дії "торгівлі", основана на перших принципах. Це ставить найосновніше питання: які етапи в процесі торгівлі повинні бути гарантовані блокчейном, а які – ні?
Відповідь:
"Процес" прагне до ефективності: подача, відповідність та оновлення замовлень — це високочастотний, швидкоплинний процес. Цей процес прагне до максимальної ефективності. Тому він розміщений у потужному поза-ланцюговому механізмі зведення. Це, в основному, вирішує "біль продуктивності" та "біль витрат".
"Результат" прагне безпеки: остаточне врегулювання угоди та передача активів є низькочастотним процесом, але необхідно гарантувати абсолютну безпеку та незмінність результату. Цей результат прагне до крайньої безпеки та остаточності. Тому він закріплюється на найбезпечнішому рівні розрахунків за допомогою технологій, таких як ZK-Rollup. Це в корені вирішує "проблему безпеки".
Суть «змішаної архітектури» полягає в ідеальному «професійній спеціалізації». Вона повертає блокчейн до того, що він робить найкраще і що він повинен робити — стати децентралізованим, ненадійним «кінцевим розрахунковим рівнем» та «судом фактів», а не незграбним «універсальним сервером», що намагається вирішити все.
Це вже не просто черговий технічний ітераційний процес. Це стрибок у мисленні. Він дає нам зрозуміти, що майбутнє DEX не полягає в тому, щоб "потужно" витримувати вимоги до продуктивності книг замовлень за допомогою більш потужних ланцюгів, а в тому, щоб "розкласти" вимоги до книг замовлень за допомогою більш розумної архітектури.
А це, можливо, є остаточною відповіддю на запитання, яке ми можемо передбачити, щодо DEX на основі книги ордерів.