a16z Crypto Останні дослідження: що є ключовим для масштабного застосування DeFi?

Автор: PGarimidi, jneu_net, @MaxResnic

Переклад: Яхвань, ChainCatcher

Сьогодні блокчейн справді можна з повним правом назвати таким, що має потрібні можливості, аби конкурувати з наявною фінансовою інфраструктурою. Виробничі системи нині здатні обробляти десятки тисяч транзакцій за секунду, і зовсім скоро ця величина зросте на порядок. Однак, окрім первинної пропускної здатності, фінансовим застосункам потрібна передбачуваність. Незалежно від того, йдеться про купівлю/продаж, ставку на аукціоні чи виконання опціону, нормальна робота фінансової системи вимагає однозначної відповіді: коли саме буде виконано цю транзакцію? Якщо транзакція стикається з непередбачуваними затримками (як навмисними, так і випадковими), багато застосунків стають непрацездатними.

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

Ключова проблема, з якою стикаються маркет-мейкери, полягає в тому, щоб з одного боку максимально звузити спред між цінами купівлі та продажу, а з іншого — уникнути ризику «несприятливого відбору» через відхилення котирувань від ринку. Для цього маркет-мейкерам доводиться постійно оновлювати свої ордери, відображаючи стан реального світу. Наприклад, якщо оголошення Федеральної резервної системи спричиняє різкий стрибок ціни активу, маркет-мейкеру потрібно негайно реагувати та оновити свої ордери до нової ціни. У такій ситуації, якщо транзакція з оновленням ордерів не буде включена відразу, маркет-мейкер понесе збитки, бо арбітражники виконають їхні ордери за застарілою ціною. Після цього маркет-мейкери змушені встановлювати ширший спред, щоб зменшити свою експозицію до таких подій, що, своєю чергою, знижує конкурентоспроможність on-chain торгових майданчиків.

Передбачуване пакування транзакцій дає маркет-мейкерам сильну гарантію: вони можуть швидко реагувати на події поза ланцюгом і підтримувати ефективність on-chain ринку.

Що ми маємо і що нам потрібно

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

Візьмімо наведений вище приклад книги ордерів: для маркет-мейкерів, якщо арбітражні транзакції можуть потрапити в більш ранні блоки, то гарантія того, що вони будуть включені «за кілька секунд у майбутньому», не має сенсу. Без сильної гарантії пакування маркет-мейкеру доводиться знижувати ризик несприятливого відбору, розширюючи спред і пропонуючи користувачам гіршу ціну. Це, своєю чергою, значно зменшує привабливість on-chain торгівлі порівняно з іншими торговими майданчиками, що надають сильніші гарантії.

Щоб блокчейн справді реалізував бачення сучасної модернізації ринку капіталу як базової інфраструктури, будівничим (констракторам) потрібно вирішити ці проблеми, аби high-value застосунки на кшталт книги ордерів могли процвітати.

Де саме на практиці виникають труднощі з передбачуваністю?

Підсилити існуючі блокчейни гарантіями пакування, які б підтримували ці use cases, — складне завдання. Деякі з нинішніх протоколів можуть покладатися на вузол, що в певний момент часу може вирішити, які саме транзакції будуть упаковані («лідер»). Це спрощує інженерні виклики для побудови високопродуктивного блокчейну, але водночас створює потенційну економічну «вузьку горловину», з якої ці лідери можуть викачувати цінність. Зазвичай у вікно, коли вузол обрано лідером, він має повну владу щодо того, які транзакції будуть упаковані в блок. Для блокчейна, що обробляє фінансову активність будь-якого масштабу, лідер перебуває в привілейованому становищі. Якщо цей єдиний лідер вирішує не пакувати певну транзакцію, єдиним способом вирішення буде чекати на наступного лідера, який погодиться її запакувати.

У permissionless мережах у лідерів є мотивація «викачувати цінність», що відоме як MEV. MEV далеко виходить за межі хіба що «вклинення» в AMM-транзакції. Навіть якщо лідер може лише відкласти пакування транзакцій на десятки мілісекунд, це вже може принести їм величезні прибутки й знизити ефективність базових застосунків. Книга ордерів, яка пріоритезує лише частину трейдерів, створює несправедливі умови для всіх інших. У найгіршому випадку лідер може стати настільки ворожим, що трейдери повністю залишать платформу.

Уявімо, що відбувається підвищення ставок, і ціна ETH одразу падає на 5%. Кожен маркет-мейкер у книзі ордерів змагається за тим, щоб скасувати свої ордери на вивантажені котирування та виставити нові ордери за новою ціною. Паралельно кожен арбітражник подає заявки продати ETH за ціною з застарілих ордерів. Якщо ця книга працює в протоколі з єдиним лідером, то влада лідера буде величезною. Лідер може просто переглянути (review) усі скасування маркет-мейкерів і таким чином дозволити арбітражникам отримати величезний прибуток. Або лідер може не перевіряти скасування напряму, а натомість відкласти їх до моменту, коли арбітражні транзакції вже будуть включені в блок. Лідер навіть може вставити власні арбітражні угоди, щоб максимально скористатися різницею цін.

Два базові запити

За наявності цих переваг активна участь маркет-мейкерів стає економічно невиправданою: достатньо лише цінової волатильності, і вони можуть опинитися «на гачку». Проблема зводиться до того, що лідери мають надто багато привілеїв у двох ключових аспектах: 1) лідер може перевіряти транзакції інших людей і 2) лідер може бачити транзакції інших та, спираючись на це, подавати свої власні транзакції у відповідь. Будь-яке з цих двох питань може виявитися катастрофічним.

Приклад

Ми можемо точно «зафіксувати» проблему на наведеному нижче прикладі. Розгляньмо аукціон із двома учасниками торгів Alice та Bob, де Bob також є лідером блоку, в якому відбувається аукціон. (Налаштування лише з двома учасниками торгів потрібне лише для пояснення; міркування однаково застосовні незалежно від кількості учасників.)

Аукціон приймає ставки протягом часу, необхідного для генерації блоку, припустімо, від часу t=0 до t=1. Alice подає ставку bA у час tA, а Bob подає ставку bB у час tB > tA. Оскільки Bob є лідером цього блоку, він завжди може гарантувати, що діятиме останнім. Alice і Bob також мають доступ до безперервно оновлюваного джерела «правди» щодо ціни активу, яке можна зчитувати (наприклад, середню ціну централізованої біржі). У час t припустимо, що ця ціна дорівнює pt. Ми припускаємо, що в кожний момент t ринок очікує, що ціна активу на момент завершення аукціону (t=1) завжди дорівнюватиме поточній реальній ціні pt. Правила аукціону прості: Alice і Bob виграє той, хто запропонував вищу ставку, і сплачує суму своєї ставки.

Потреба в антицензурності

Тепер подивімося, що станеться, якщо Bob може скористатися перевагою лідера саме в цьому аукціоні. Якщо Bob може перевіряти ставки Alice, то аукціон очевидно зруйнується. Оскільки інших учасників немає, Bob має просто зробити ставку на довільно малу суму — і тим самим гарантувати перемогу. У підсумку при розрахунках аукціону прибуток фактично дорівнює 0.

Прихована потреба

Складніший випадок — якщо Bob не може напряму перевіряти ставку Alice, але все одно може бачити ставку Alice до того, як зробить власну ставку. Що станеться в такому разі? У Bob є проста стратегія. Коли він робить ставку, йому достатньо перевірити, чи виконується умова ptB > bA. Якщо так, то його ставка лише трохи вища за bA; якщо ні — він взагалі не робить ставки.

Виконуючи цю стратегію, Bob змушує Alice зіткнутися з несприятливим відбором. Єдиний випадок, коли Alice виграє — це коли оновлення ціни змусить її ставку в кінцевому підсумку виявитися вищою за очікувану вартість активу. Колиразу, коли Alice виграє аукціон, вона очікує, що зазнає збитків, і їй було б краще взагалі не брати участь в аукціоні. Коли всі конкуренти зникають, Bob знову може просто зробити ставку на довільно малу суму й перемогти, і аукціон фактично отримає 0 прибутку.

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

Ті самі принципи з цього прикладу застосовні до будь-якого середовища високочастотної торгівлі активами — як для спот-торгів, так і для торгів вічними контрактами чи в деривативних біржах: якщо в цьому прикладі існує лідер із повноваженнями, якими володіє Bob, то він може спричинити повний колапс ринку. Щоб on-chain продукти, які обслуговують ці use cases, стали реально життєздатними, вони ніколи не повинні надавати лідерам такі повноваження.

Як ці проблеми проявляються на практиці сьогодні?

Історія вище малює похмуру картину для будь-якого on-chain середовища з протоколом із permissionless єдиним лідером. Проте чому тоді обсяг торгів у децентралізованих біржах (DEX) із єдиним лідером продовжує залишатися здоровим? На практиці це компенсують дві сили разом:

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

Хоч ці два фактори донині підтримували роботу DeFi, у довгостроковій перспективі вони недостатні, щоб on-chain ринки по-справжньому конкурували з off-chain.

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

По-перше, спиратися на добру волю операторів вузлів через суспільний тиск і апелювати до їхніх довгострокових мотивів — це не є надійна база для фінансового майбутнього. Зі зростанням масштабу on-chain фінансової активності потенційна прибутковість лідерів також зростає. Чим більший цей потенціал, тим складніше (на рівні суспільства) змусити лідерів діяти всупереч їхнім безпосереднім вигодам «прямо зараз».

По-друге, ступінь, у якому лідери можуть використовувати свою ринкову владу, лежить на спектрі від «доброякісного» до такого, що призводить до повного колапсу ринку. Оператори вузлів можуть в односторонньому порядку використовувати свої повноваження задля отримання вищого прибутку. Коли деякі оператори починають порушувати загальновизнані «межі допустимого», інші швидко починають наслідувати їх. Поведінка одного вузла може здаватися незначною, але коли так роблять усі, вплив стає очевидним.

Можливо, найкращим прикладом такого явища є ігри з таймінгом (Timing Games): лідери намагаються оголошувати про створення блоку максимально пізно, поки протокол усе ще працює, щоб отримувати більші винагороди. Коли лідери поводяться надто агресивно, це збільшує час створення блоків і спричиняє «стрибаючу» їх генерацію. Хоча прибутковість цих стратегій широко відома, лідери все ж обирають не грати в ці ігри здебільшого для того, щоб виступати як «хороші адміністратори» блокчейну. Але це крихка соціальна рівновага. Щойно один оператор починає грати в ці стратегії заради вищих винагород і без жодних наслідків, інші оператори швидко приєднаються.

Ігри з таймінгом — лише один приклад того, як лідери можуть збільшувати свою прибутковість, не використовуючи повною мірою власну ринкову силу. Лідери також можуть вдаватися до багатьох інших дій, жертвуючи застосунками заради власних винагород. Якщо розглядати окремо, ці дії можуть бути прийнятними для застосунків, але врешті-решт «терези» мають схилитися в точку, де витрати on-chain починають перевищувати вигоди.

Ще одним фактором, що підтримує роботу DeFi, є те, що застосунки переносять важливу логіку в off-chain, публікуючи лише результати в on-chain. Наприклад, будь-які протоколи, яким потрібні швидкі аукціони, виконують їх у off-chain. Зазвичай ці застосунки працюють у наборі permissioned вузлів, щоб уникнути проблем із зловмисними лідерами. Наприклад, UniswapX проводить свою голландську аукціонну процедуру поза основною мережею Ethereum, щоб завершити торгівлю; аналогічно CowSwap проводить batch-аукціони у off-chain.

Хоч це і підходить для застосунків, воно ставить ціннісну пропозицію базового рівня та on-chain збірок у небезпечне становище. У світі, де логіка застосунку виконується в off-chain, базовий рівень чисто перетворюється на рівень розрахунків. Один із найсильніших аргументів DeFi — композабельність. Коли всі виконання відбуваються в off-chain, ці застосунки по суті живуть у ізольованому середовищі. Покладання на off-chain виконання додає до моделі довіри застосунків нові припущення. Робота застосунків більше не залежить лише від активності базового ланцюга — і ця off-chain інфраструктура також має працювати справно.

Як отримати передбачуваність

Щоб вирішити ці проблеми, протокол має відповідати двом властивостям: узгодженому пакуванню транзакцій і правилам сортування, а також прихованості транзакцій до їх фіналізації (про строгі визначення цих властивостей та розширене обговорення див. цю статтю).

Базова вимога 1: антицензурність

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

Короткострокова антицензурність: будь-яка чинна транзакція, яка надходить вчасно на будь-який чесний вузол, обов’язково буде включена в наступний можливий блок.

Більш точно, ми припускаємо, що протокол працює за фіксованим годинником: кожен блок генерується у встановлений час, наприклад кожні 100 мілісекунд. Тоді нам потрібно гарантувати, що якщо транзакція прибуває на чесний вузол у t=250ms, її буде включено в блок, який генерується в t=300ms. Суперник не має права вибірково вирішувати, якісь транзакції зі свого «почутого» набору запакувати, а інші — пропустити.

У цьому визначенні закладена ідея, що і користувачі, і застосунки мають мати надзвичайно надійний спосіб зробити так, щоб транзакція була виконана в будь-який момент часу. Не має відбуватися ситуації, коли окремий вузол випадково «втрачає пакет» (через зловмисність чи через просту відмову в роботі), через що транзакція не може бути включена. Хоча це визначення вимагає надання гарантії пакування для транзакцій, що доходять до будь-якого чесного вузла, на практиці реалізувати це може бути занадто дорого. Важлива характеристика полягає в тому, що протокол має бути стійким, аби поведінка точки входу в on-chain була надзвичайно передбачуваною та піддавалася міркуванням.

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

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

Базова вимога 2: прихованість

Після короткострокової антицензурності наступною за важливістю властивістю є форма приватності, яку ми називаємо «прихованість».

Прихованість: до того, як протокол фіналізує пакування транзакцій, жодна зі сторін, окрім вузла, який отримав цю транзакцію, не може отримати будь-яку інформацію про неї.

Протокол із властивістю «прихованість» може дозволяти вузлам переглядати вхідні до них транзакції у відкритому вигляді, але вимагати, щоб решта частин протоколу залишалася «сліпою» до моменту досягнення консенсусу та визначення порядку транзакцій у фінальному журналі. Наприклад, протокол може використовувати криптографію із часовими замками, щоб приховати повний вміст блоків до певного дедлайну; або протокол може використовувати порогове шифрування, щоб негайно розшифрувати блок одразу після того, як комітет погодиться незворотно підтвердити його.

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

Ми відмовляємося від використання сильнішого поняття, за якого користувач дізнається будь-яку інформацію лише після того, як транзакції підтверджуються, (наприклад, у криптовому mempool), тому що протокол має виконати певні кроки як фільтр від сміттєвих транзакцій. Якщо вміст транзакцій повністю приховано від усієї мережі, мережа не зможе відфільтрувати сміттєві транзакції від осмислених. Єдиний спосіб розв’язати цю проблему — розкрити певні метадані як частину транзакції, наприклад адреси платника комісії, незалежно від того, валідна транзакція чи ні.

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

Протокол, який одночасно має короткострокову антицензурність і прихованість, створює ідеальну основу для побудови фінансових застосунків. Повернемося до нашого прикладу з аукціоном on-chain: ці дві властивості безпосередньо вирішують спосіб, яким Bob міг спричинити колапс ринку. Bob не може ні перевіряти ставки Alice, ні використати ставки Alice, щоб отримати інформацію для своєї власної ставки — і це саме усуває проблеми нашого попереднього прикладу.

Завдяки короткостроковій антицензурності будь-хто, хто подає транзакцію (чи то транзакцію, чи ставку на аукціон), може бути впевнений, що її буде негайно включено. Маркет-мейкери можуть змінювати свої ордери; учасники торгів можуть швидко робити ставки; кліринг може ефективно завершуватися. Користувачі можуть бути впевнені, що будь-які дії, які вони здійснюють, будуть виконані миттєво. Це, своєю чергою, дозволить наступному поколінню низьколатентних реальних фінансових застосунків повністю будуватися on-chain.

Щоб блокчейн справді конкурував із наявною фінансовою інфраструктурою — і навіть перевершив її — нам потрібно вирішити не лише проблему пропускної здатності.