Автор: Pavel Paramonov Джерело: X, @paramonoww Переклад: Шано, Золоті фінанси

Багато людей вважають, що "ASS - все, що вам потрібно", вважають його повним рішенням, практично не потребує поліпшень. Однак ASS не може вирішити всі проблеми, він також ґрунтується на деяких припущеннях щодо довіри.

1. Децентралізована програма (dApp) з автоматичною серіалізацією є частиною Блок конструктора

Коли угода увійшла в Блок, додаток має право видобути свою власну максимальну вартість, що видобувається (MEV) з цього Блоку, отримуючи свою вартість від інших "членів" MEV Мережі постачання, таких як пропоненти, пошуковці та конструктори. Однак ця концепція, як і все в шифруванні, не є ідеальною, і може містити певні припущення щодо довіри.

2. ігри щодо включення

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

Це цікава сцена міркування:

• dApp має здатність захоплювати всі MEV, які вона генерує
• Проте якщо втратити не лише можливість MEV, а й користувачів, які можуть принести значення платформі (наприклад, якщо AMM продовжуватиме зазнавати невдач, хто буде використовувати його), це буде безглуздо.

Найцікавіше в тому, що пропонент також повинен отримувати прибуток, що створює ситуацію подвійної виграшу-програшу:

• Децентралізовані додатки (dApp) втрачають можливість отримувати MEV, оскільки їх самовиразність не включена у Блок.
• Пропонент втратив MEV через неможливість розпакування та перепакування зв'язок атомів (хоча вони можуть вибрати іншу угоду)

3. ASS dApp не повинен завдавати шкоди звичайним користувачам та постачальникам ліквідності (LPs) шляхом видобутку MEV

Як відомо, більшість MEV генерується та вилучається через токсичний трафік. LP втрачають більшість свого доходу від неінформованого трафіку через MEV. Приваблення Ліквідності на платформу є однією з найскладніших задач у сферішифрування, а AMM маєсправедливо розподіляти MEV між LP, що може допомогти зменшитиНепостійні втрати.

У сучасній реальності активне управління позицією LP (навіть кількома позиціями LP) може розглядатися як повноцінна робота. Якщо це атака на сендвіч, то значення повертається трейдеру; якщо це арбітраж між централізованою біржею і децентралізованою біржею, то значення повертається LP. Отже, питання полягає в тому, скільки вони мають отримати винагороду, а скільки вартості має залишити dApp?

4. Що робити, якщо розмір зв'язаного об'єкта конфліктує з розміром блоку Блокчейну?

Очевидно, не всі dApp автоматично серіалізуються (принаймні найближчим часом). Розмір Блоку (або пакету транзакцій) обмежений; якщо немає обмежень, то немає Блокчейну або Блокчейну. Припустимо, що один Блок може містити максимум 100 транзакцій, можуть виникнути такі ситуації:

• dApp надіслала пакет з 100 транзакцій, який заповнив весь Блок. Яким є потенційний прибуток для інших "учасників" Мережі постачання MEV, якщо вони включають його, пропонують Блок і виконують його?
• dApp відправив зв'язку, що містить 99 транзакцій, залишилося 1 місце. Чи є достатньою мотивація для пропонента, щоб включити цей зв'язок? (Якщо вони не зроблять попередню угоду, то так)
• Два додатки dApp відправили зв'язані. Перший зв'язаний містить 60 операцій, другий - 50 операцій. Очевидно, можна включити тільки один зв'язаний.

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

Так хто повинен бути включений? Хто в Блоку найбільш прибутковий, а не просто зв'язаний в середині?

Можливим рішенням є FCFS (перший прийшов - перший отримав), але воно не гарантує точності, оскільки затримка все ще існує.

Як забезпечити, щоб серіалізація була корисною для всіх, а не лише для одного учасника, інші учасники (LPs, користувачі) не були позбавлені вартості?

Потенційним рішенням є встановлення конкретних правил серіалізації, за якими можна впорядкувати зв'язки тільки в разі дотримання цих правил. Це важливо, оскільки неправильна серіалізація може призвести до вразливостей безпеки.

Для торговельних пар AMM використання правил перевірки на жадібність може запобігти передній атакі в конкретному пулі AMM. Однак більшість торгів у DEX - це складні багаторазові обміни, тому потрібен інший спосіб гарантування захисту від MEV.

Ще досі ранній етап!

Зараз існує кілька способів для самопослідовності, я був натхненний підходом @SorellaLabs до цієї теми. Ми все ще знаходимося на ранній стадії впровадження самопослідовності (або ASS, як каже @ballsyalchemist), різні інфраструктури мають різні компроміси.

ASS має на меті зробити так, щоб dApp відповідав за свою серіалізацію, а не за виконання (що обробляється ланцюгом). Хоча на рівні L1 ASS відносно чіткий, на L2 він більш привабливий, оскільки потрібно обробляти лише один серіалізатор, і L2 може забезпечити більше контенту, виконуючи місцеві правила серіалізації.

зростання простору величезнеz！（Блок простір вилучено）