Токени Рівня 2 як оплата транзакційних зборів: Технічний аналіз

Ця технічна стаття розглядає переваги та недоліки дозволу користувачам оплачувати комісії за транзакції за допомогою рідних токенів Рівня 2, аналізуючи як технічні механізми, так і ринкові наслідки.

Передумови

Розуміння механізмів роботи Rollup та механізмів примусового включення рекомендоване для повного усвідомлення цього аналізу.

Вступ

Більшість мереж Рівня 2 випускають власні токени, хоча багато з них в основному використовуються для цілей управління (, таких як Arbitrum та Optimism). Деякі протоколи L2 впровадили механізми стейкінгу для своїх рідних токенів, зокрема Mantle та Manta. Ці токени, що знаходяться в стейкінгу, виконують різні функції, такі як визначення авторитету послідовності транзакцій, потужність генерації нульових доказів або забезпечення дотримання вимог публікації даних. Для технічних деталей зверніться до документації StarkNet, zkSync, Mantle та Manta.

Технічна примітка: Об'єктивна перевірка "правильної публікації даних" становить суттєві виклики, що ускладнює реалізацію ефективних механізмів покарання. Це піднімає питання про ефективність дизайнів, які покладаються на "стейкінг токенів Рівень 2 для функціональності публікації даних."

Оплата збору за нативний токен: Технічний та ринковий аналіз

Технічні переваги

Впровадження нативних токенів рівня 2 як механізмів оплати комісій значно розширює утиліту токенів за межі базових функцій управління. Цей підхід можна вдосконалити, впровадивши механізми EIP-1559 для спалювання частини токенів, зібраних як комісії, що потенційно створює дефляційний тиск, який сприяє накопиченню вартості в екосистемі.

Технічні обмеження

Виклик деномінації витрат даних

Основна проблема залишається в тому, що Sequencers Rollup повинні сплачувати витрати на доступність даних в рідній валюті L1 (ETH) при завантаженні даних транзакцій до Ethereum. Це створює вбудований ризик курсової різниці між моментом, коли Sequencer отримує токени L2 як оплату, і моментом, коли їм потрібно конвертувати ці токени в ETH для витрат на доступність даних. Ця ризикована експозиція додає операційну складність для операторів Sequencer.

Технічна примітка: Це питання виходить за межі Rollup-ів на основі Ethereum. Мережі Рівня 2, які використовують альтернативні шари доступності даних (, такі як Mantle або Manta), стикаються з ідентичними викликами, пов'язаними з рідним токеном відповідного шару DA.

Вплив на користувацький досвід

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

Наприклад, користувачі, які вперше вносять ETH на Polygon PoS, виявляють, що не можуть використовувати цей ETH для сплати комісії за транзакції. Без токенів MATIC, які вже є в їхньому гаманці, вони не можуть виконати транзакцію, необхідну для обміну ETH на MATIC. Це змушує користувачів спочатку придбати MATIC на L1, а потім перенести його до середовища L2.

Технічна примітка: Хоча Polygon PoS технічно є сайдчейном, а не справжнім Рівнем 2, цей приклад ефективно ілюструє виклик у користувацькому досвіді.

Цей тертя множиться в екосистемі - з N різними мережами Рівня 2, які потребують N різних токенів для базових операцій.

Перешкоди міжоперабельності Cross-L2

Вимоги до комісій за рідний токен створюють значні технічні бар'єри для безперешкодної взаємодії Рівня 2. Наприклад, базовий між-L2 переказ не може бути завершений лише з ETH, якщо цільовий L2 вимагає свій рідний токен для комісій за транзакції.

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

Візія Superchain Optimism щодо інтерактивності ілюструє цю проблему ідеально - якщо кожен Rollup в екосистемі Superchain вимагав би різних токенів для сплати комісій, це безпосередньо підірвало б основні цілі інтерактивності.

Однак ці обмеження досвіду та інтероперабельності стосуються лише ексклюзивних моделей комісій з рідних токенів. Гібридні підходи, які підтримують як ETH, так і рідні токени для сплати комісій, можуть пом'якшити ці проблеми, дозволяючи користувачам обирати ETH для міжланцюгових операцій, в той час як вони можуть використовувати токени L2 для рідних операцій, якщо це потрібно. StarkNet є піонером цього гібридного підходу, впроваджуючи підтримку як ETH, так і STRK для сплати комісій.

Технічна реалізація: STRK як комісія за транзакцію

StarkNet нещодавно оголосив про підтримку платежів за допомогою токена STRK разом з ETH. Ця модель плати з двома валютами дозволяє користувачам обирати бажаний метод оплати, тоді як Секвенсер (, який у термінах StarkNet називається "Оператором", ) бере на себе ризик зміни курсу між ETH та STRK. Це піднімає важливі технічні питання щодо визначення комісій за транзакції.

Технічний аналіз авторитету секвенсера

На мережах як L1, так і L2 транзакції зазвичай вказують максимальну плату, яку користувач готовий сплатити. На сумісних з EIP-1559 ланцюгах (Ethereum, Arbitrum, Optimism) користувачі вказують значення maxFeePerGas, яке, помножене на gasLimit, визначає максимальну плату за транзакцію. Ланцюги, несумісні з EIP-1559, використовують моделі фіксованої плати.

Технічна примітка: StarkNet, хоча ще не реалізував EIP-1559, вимагає від користувачів вказати параметр maxFee.

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

Аналіз впровадження Oracle

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

Критичним фактором залишається максимальний збір, який вказує користувач ( в ETH або STRK), після чого вони повинні чекати на включення. Публічний орієнтир обмінного курсу не змінить цю взаємозв'язок, оскільки секвенсори зберігають можливість стягувати до повного вказаного максимального збору.

Офлайнова архітектура оракулів для StarkNet

STRK котирування, спеціально для операцій секвенсорів. Це піднімає важливі питання технічного управління: як спільнота може перевірити, що секвенсори розраховують комісії STRK відповідно до цих котирувань оракула?

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

Вимоги до механізму примусового включення

Механізм Force Inclusion представляє собою більш переконливий випадок використання для інтеграції ораклів. Коли користувачі активують Force Inclusion з L1 (, щоб обійти секвенсори L2 ), вони повинні сплатити збори за виконання L2 на рівні L1. Наприклад, функція depositTransaction у Optimism знищує газ відповідно до вказаного ліміт газу L2, ефективно стягуючи ETH на L1. Аналогічно, requestL2Transaction у zkSync обчислює основні витрати на транзакції L2 і вимагає достатньо ETH у транзакції L1.

Якщо ці протоколи Рівня 2 впроваджують плату за транзакції у вигляді нативних токенів, механізми примусового включення стикаються з критичною технічною проблемою: як справедливо визначити плати в ETH на L1 за транзакції, які зазвичай коштують токенів L2? Без точних обмінних курсів це може несправедливо покарати користувачів Force Inclusion через надмірні збори або дозволити зловмисникам експлуатувати штучно низькі збори.

Цей конкретний сценарій демонструє переконливий випадок використання інтеграції оракулів - дозволяючи контрактам L1 справедливо розраховувати збори за транзакції Force Inclusion.

Альтернативно, протоколи Рівня 2 можуть стандартизувати свої рідні токени для звичайних та примусових транзакцій, усуваючи потребу в перетворенні між валютами. Проте витрати на доступність даних залишаються в ETH, створюючи гібридну модель комісій, де примусові транзакції вимагають як ETH ( за дані ), так і токенів Рівня 2 ( за виконання ) - технічне завдання, яке розробники Рівня 2 повинні вирішити при впровадженні моделей комісій з рідними токенами.

Технічний синтез

• Токени L2 можуть виконувати кілька технічних функцій, а сплата зборів представляє собою значне розширення утиліти за межами управління.

• Основною перевагою моделей комісій у рідних токенах є встановлення чіткої корисності токена з потенційними дефляційними механізмами через впровадження EIP-1559.

• Технічні недоліки включають підвищений ризик впливу секвенсора, тертя у користувацькому досвіді та бар'єри в інтероперабельності в екосистемі Рівня 2.

• Гібридні моделі зборів, що підтримують як ETH, так і рідні токени, можуть зберігати користувацький досвід та інтероперабельність, одночасно забезпечуючи утилізацію токенів.

• StarkNet впроваджує гібридний підхід з підтримкою зборів за токен STRK, реалізуючи офлайн-орендні ціни для секвенсерів.

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

• Інтеграція Oracle надає обмежені переваги для стандартних транзакцій, але стає критично важливою для механізмів примусового включення, де конверсія між валютами впливає на безпеку та справедливість.

• Реалізації примусової інклюзії з комісіями за нативні токени створюють складні технічні виклики, потенційно вимагаючи від користувачів сплачувати як ETH ( за доступність даних ), так і токени L2 ( за комісії за виконання ) в одній транзакції.