Вступ

У нашому попередньому пост 15Ми представили модель ERC-4337. Ця модель визначає структуру ринку комісій для пакувальників та деталізує функцію витрат, пов'язаних із витратами на публікацію on-chain та off-chain (витрати на агрегацію) пакета.

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

Це дослідження має на меті дослідити методи покращення UX, забезпечуючи, що користувачам не потрібно переплачувати за включення в наступний пакет. Замість цього, користувачі повинні мати можливість сплатити плату, засновану на фактичному попиті на ринку для включення.

Поточний стан ERC-4337

На сьогоднішньому ринку P2P mempool не працює на основній мережі і його тестують на тестнеті Sepolia. Компанії, які будують на ERC-4337, наразі працюють в приватному режимі, користувачі підключаються через RPC до приватного бандлера, який потім працює з білдером для публікації вашої useroperation onchain.Додаток Bundle Bear 3, розроблений Кофі, надає цікаві статистичні дані про поточний стан ERC-4337.

В Щотижневий % багатокористувацький набір 1У метриці ми спостерігаємо відсоток бандлерів, які створюють пакети, які включають кілька користувацьких операцій. З початку 2024 року до червня 2024 року цей відсоток не перевищував 6,6%. Ці дані стають ще цікавішими, коли беремо до уваги, що багато бандлерів працюють зі своїми власними платниками, суб'єктами, які спонсорують транзакції від імені користувачів. Зокрема, два найбільших бандлера, які також працюють як платник, за обсягом операцій користувачів, опублікованих,спонсоровано 97% 1 операцій користувача з використанням його сервісів. Paymaster оплачує деякі частини роботи користувача, а решту оплачує dapps або інші сутність 1.

Те, що виникає питання, чому платники, dApps і т. Д., Платять за операції користувачів. Чи будуть користувачі повертати їм кошти у майбутньому? Ми не можемо бути впевнені, що станеться, але моє особисте припущення полягає в тому, що наразі dApps покривають комісії для збільшення використання та прийняття своїх додатків. Якщо прийняття буде високим, ймовірно, користувачам доведеться самостійно платити за транзакції. Варто зазначити, що для того, щоб користувач оплатив операцію користувача за поточною моделлю, це не найкращий варіант, оскільки базова операція ERC-4337 коштує приблизно 42,000 газу, тоді як звичайна транзакція коштує приблизно 21,000 газу.

Варіації на ERC-4337

Огляд ERC-4337

Мемпул все ще знаходиться на стадії тестування на Sepolia і не працює в основній мережі. Без мемпулу користувачі мають обмежені можливості використання абстракції облікового запису. Користувачі взаємодіють з RPC, який може бути запропонований бандлером, який об'єднує UserOps, або з RPC-сервісом, який не об'єднується, подібно до сервісів на кшталт Alchemy або Infura, які отримують і пропаGate транзакції іншим бандлерам.

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

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

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

Бандлери та будівельники як дві різні сутності

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

Використання мемпулу, в якому userops є публічними для різних бандлерів, збільшує конкуренцію, у випадку нерідної абстракції облікового запису потрібне розділення між bundler та builder, у випадку нативної абстракції облікового запису поділ може не знадобитися, оскільки розробник може інтерпретувати userops як звичайні транзакції.

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

RIP-7560

Загальна абстракція облікового запису - це не новий концепт; вона вивчалася протягом років. Хоча ERC-4337 набирає популярність, його впровадження поза протоколом пропонує визначені переваги поруч з компромісами. Зокрема, існуючі EOAs не можуть безперешкодно переходити до SCWs, а різні типи списків, які стійкі до цензури, складніше використовувати. Як вже зазначалося, вартість користувацького операційного кошту зростає значно порівняно зі звичайною транзакцією.RIP-7560 2не вирішить в собі питання, що стосується витрат поза ланцюгом, але значно зменшить витрати на транзакції. З початкових ~42000 газів можливо зменшити витрати на~20000 газу.

Обліковий облік Layer2s

Абстракція рахунку може бути використана в рішеннях рівня 2 (L2). Деякі L2 вже реалізують його нативно, тоді як інші дотримуються підходу L1 і чекають на нову пропозицію, аналогічну RIP-7560. У L2 L1 використовується для доступності даних для успадкування безпеки, тоді як більша частина обчислень відбувається поза мережею на L2, забезпечуючи дешевші транзакції та масштабованість.

У випадках, коли обчислення на L2 значно дешевше, ніж вартість calldata для доступності даних (DA) на головному ланцюжку, використання агрегації підписів доводиться дуже корисним. Наприклад, з'єднання для BLS на головній мережі сприяє0x08 1предкомпілювання з EVM, що коштує приблизно ~45000k газу. Відповідно, використання BLS на L1 є дорожчим, ніж традиційні транзакції.

Техніки стиснення на рівні L2 вже використовуються, наприклад, стиснення 0 байт, яке зменшує вартість з приблизно 188 байтів до приблизно 154 байтів для передачі ERC20. Зі збіркою підписів ефективність стиснення може бути ще більш підвищена за допомогою одного підпису, зменшуючи розмір до приблизно 128 байтів.

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

Економіка агрегації підписів в Layer2s

При використанні послуги L2 користувач несе кілька витрат, включаючи плату за оператора L2, вартість, засновану на перевантаженні мережі, і вартість доступності даних на L1.

З попередніх досліджень щодо «Розуміння економіки роллапу з перших принципів", ми можемо виділити витрати, з якими стикається користувач при використанні служб L2, наступним чином:

Коли користувач взаємодіє з рівнем 2, в нього є певні витрати, які ми можемо визначити таким чином:

• Плата користувача = плата за публікацію даних L1 + плата оператора L2 + плата за затор L2
• Вартість оператора = Вартість оператора L2 + Вартість публікації даних L1
• Дохід оператора = Користувацькі комісії + MEV
• Прибуток оператора = Дохід оператора - Витрати оператора = плата за перевантаження L2 + MEV

У випадку ненативної абстракції облікового запису, додаткова сутність, бандлер, може вводити плату за створення пакетів userops.

Розглядаючи бандлер, витрати та прибутки розширюються наступним чином:

• Плата користувача = Плата за публікацію даних рівня L1 + Плата оператора рівня L2 + Плата за затори рівня L2 + Плата за зв'язувач
• Вартість пакета = Цитована (оплата за публікацію даних рівня L1 + комісія оператора рівня L2 + комісія за затор рівня L2)
• Дохід від пакетів = Користувацька плата
• Прибуток пакувальника = Дохід пакувальника - Вартість пакувальника = Різниця між витратами на рівні L1 та L2 та ціновими пропозиціями від пакувальника + Плата пакувальника
• Вартість оператора = плата за публікацію даних на рівні L1 + плата оператора на рівні L2
• Прибуток оператора = Дохід оператора - Витрати оператора = плата за перевантаження L2 + MEV

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

Спільна мотивація на рівні L2

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

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

Витрати, пов'язані з створенням пакета та його публікацією на ланцюжку, можна розділити на дві частини:

Функція вартості on-chain: бандлер, видавши пакунок B, коли базова комісія становить r, витрачає витрати:

Функція агрегованої вартості: Бандлер має функцію вартості для агрегування n транзакцій в один пакет B з базовою платою r:

з S′F, яка містить публікацію та перевірку єдиного ончейн-агрегованого підпису.

Якщо користувач може отримати достовірну оцінку для n, він може розрахувати їх вартість за допомогою функції estimateGas, доступної в більшості рішень L2. Маючи хорошу оцінку, користувач може зробити відповідну ставку, не переоцінюючи свою ставку для включення. Ця функція визначає необхідні витрати для забезпечення інклюзії. Наявність хорошої оцінки для n і функції estimateGas може уникнути того, щоб користувач платив за вищу preVerificationGas. У наступному розділі ми розглянемо різні механізми для забезпечення надійної оцінки n.

Layer2s працюють оракулом

Роль оракула полягає в моніторингу мемпулу та оцінці кількості присутніх транзакцій. Процес працює наступним чином: рівень 2 розгортає оракул для перевірки мемпулу, а потім інформує користувача про кількість транзакцій у мемпулі. Це дає змогу користувачеві оцінити свою ставку для включення в пакет. Рівень 2 може попросити бандлера включити принаймні вказану кількість транзакцій (n) у пакет, інакше пакет буде відхилено. Після того, як бандлер збирає достатню кількість транзакцій для формування бандла, він відправляє пакет на рівень 2, який потім пересилає його в основну мережу як calldata для доступності даних.

Пропозиція спостерігача691×642 47.4 KB

Layer2s зі спільним секвенсором

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

У цій конфігурації різні мережі L2 працюють незалежно один від одного, але мають спільний секвенсор. Через регулярні проміжки часу ці мережі перевіряють кількість операцій користувача (userops) у спільному мемпулі. Спільний секвенсор допомагає синхронізувати та aggreGate дані з цих мереж. Як тільки вони досягають згоди, інформація передається користувачеві, що дозволяє йому робити ставки на основі кількості присутніх користувачів.

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

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

Shared Sequencer764×785 66.3 KB

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

н

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

Layer2s працюють з власним пакувальником

У цій пропозиції сам рівень 2 виступає у ролі збирача, тоді як інша сутність відповідає за агрегацію підписів (це можуть бути поточні служби збирача). Процес працює наступним чином: рівень 2 працює зі своїм власним збирачем, а користувачі надсилають свої операції (userops) в пам'ять. Рівень 2 вибирає деякі з цих операцій з пам'яті та надсилає їх «чистими» до агрегатора, компенсуючи агрегатор за агрегацію підписів. Після того, як агрегатор створить пакет, він надсилає його збирачу, який потім пересилає його на головну мережу як calldata для доступності даних.

Основна ідея полягає в тому, що Layer 2 відповідає за збір userops, а потім передає агрегацію іншій сутності. Layer 2 оплачує агрегацію і стягує з користувача плату за послугу.

Є два різних варіанти:

1. Модель фіксованої плати: Бандлер (Сиквенсер) вибирає деякі транзакції і стягує з користувача фіксовану плату. Ця фіксована плата розраховується так само, як і поточні транзакції Layer 2, передбачаючи майбутню вартість публікації даних на L1. Інший варіант - Layer 2 може стягувати з користувача фіксовану плату на основі вартості упаковки n
2. Узагальнені користувацькі операції, шар 2 все ще повинен передбачити, скільки транзакцій буде присутні в пакеті, який він побудує, щоб правильно процитувати користувача, це можна зробити таким же чином, як зараз, де . Так, як зараз l2 рахує найкращу конкурентоспроможну ціну для користувача, це в найкращих інтересах шару 2 зберігати ціни якомога більш конкурентоспроможними для користувача.
   
3. Flat Fee671×702 22.1 KB
4. Запит на повернення коштів: Якщо Layer 2 хоче покращити свою довіру, він може увімкнути автоматичне повернення коштів. Це передбачатиме механізм, який перевіряє, скільки userops публікуються в одному блоку і чи можуть транзакції бути агрегованими. Якщо userop, який міг бути агрегованим, не був агрегованим, і не було надано автоматичне повернення коштів, користувач може подати запит на повернення коштів. В цьому сценарії Layer 2 може заложити деякі активи, і якщо повернення коштів не надано, користувач може змусити його надати, забезпечуючи справедливість та відповідальність.
   
5. Запит на повернення 671×702 22.8 KB

Висновок

У цих двох різних постах ми наводимо складнощі, з якими користувачі стикаються, коли намагаються бути включеними в наступний пакет. У першій частині ми представили модель ERC-4337, пояснивши витрати, які зазнає пакувальник при публікації пакета on-chain та пов'язані off-chain витрати. Ми також навели ринки комісій для пакувальників та почали обговорювати проблему форматування пакувальника. Користувачі стикаються з труднощами щодо ставок через відсутність знань про кількість транзакцій, присутніх у мемпулі на момент упаковування.

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

Відмова від відповідальності:

1. Ця стаття переписана з [ Етрезер], Пересилайте оригінальний заголовок «Вбудовані ринки комісій та ERC-4337 (частина 2)», Усі авторські права належать оригінальному автору [ DavideRezzoli & Barnabé Monnot ]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно цим займуться.

2. Відмова відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.

3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.