Механізми комісій за транзакції стали моделями для розуміння посередництва виробників блоків між користувачами, які бажають здійснити транзакцію, і «ланцюжком» (або «протоколом»), на якому користувачі здійснюють транзакції. З огляду на можливість використовувати частину пропозиції, що надається ланцюгом, виробники блоків повинні арбітражувати, які користувачі матимуть можливість використовувати обмежений ресурс ончейн-виконання і за яку ціну. На Ethereum у питанні вартості виробники блоків обмежені механізмом комісії EIP-1559, який динамічно встановлює резервну ціну від блоку до блоку, яка називається «базовою комісією». Базова комісія – це ціна, виражена за одиниці газу, яку має заплатити транзакція користувача, щоб бути включеною та виконаною. Користувач може надавати так звані «пріоритетні збори» понад базову плату, щоб ще більше стимулювати виробників блоків у часи перевантаження.

У цій замітці ми розглянемо питання про вбудовані ринки комісій, тобто ринки комісій, які «живуть» на інших ринках комісій. Це питання обговорювалося в іншому контексті в нещодавній статті Мар'ям Бахрані, Пранава Гаріміді та Тіма Роугардена: «Дизайн механізму комісії за транзакції в пост-MEV світі 9”. У цій роботі автори моделюють використання пошукових систем, подальшого посередництва в доступі до ланцюга між користувачами та виробниками блоків. Виробники блоків отримують “підказки” від пошукових систем, що виражені атомними пакетами транзакцій, які мають бути включені в ланцюг. Ринок винагороди пошукових систем приводиться до максимізації об'єктиву кількості, відомої як MEV, або максимально можлива витягувана вартість.

У наших налаштуваннях користувачі бажають отримати доступ до ланцюжка, але не висловлюють свою вимогу за допомогою розбірливих транзакцій. Натомість, користувачі виробляють «операції», які об'єднуються сутностями, відомими як «бандлери», які потім ініціюють розбірливу транзакцію, упаковуючи операції разом для виконання. Таким чином, відповідно до механізму комісії EIP-1559, бандлери є користувачами ланцюга, але фактичні користувачі повинні спочатку отримати включення до пакета бандлера, перш ніж вони зможуть отримати включення до ланцюга. Іншими словами, ми можемо розглядати цю установку як частину ширшого питання про блок співтворення, що виникає з (частковими) будівельниками/пошуками, а також списками включення.

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

Для розслідування відмінності між прямими ринками комісій та їх вбудованими (під-)механізмами ми повинні уточнити економічні обмеження, яким клятій пакувальник. У наступному розділі ми пропонуємо просту модель функції вартості пакувальника, мотивовану практикою, зокрема пакувальниками, які беруть участь в протоколі ERC-4337, про який ми коротко резюмуємо.

Модель

Bundling in ERC-4337

Користувач, який бажає виконати певну діяльність у мережі через бандлери, видає Операцію користувача (UserOp, або операцію). Цей UserOp випускається з гаманця користувача, наприклад, після взаємодії з DApp. Після того, як UserOp транслюється, якийсь бандлер, який отримує операцію, може вирішити включити її в пакет. Бандл — це метатранзакція «зовнішнього облікового запису» (EOA), яка записує дані включеного UserOps у своє поле bundle.calldata. Бандлер видає бандл для включення в блок блок-продюсером (ми обговоримо зв'язок між бандлером і блок-продюсером в наступній примітці).

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

• Передперевірка: Транзакція EOA пакувальника буде витрачати 21 000 газу, а виклик до контракту EntryPoint налаштує ключові змінні для відстеження виконання операцій у циклі операцій.
• Операційний цикл 3: Для кожної операції, включеної в пакет, відбуваються наступні два кроки:
  • Крок перевірки: UserOps виконує операції, що містять крок перевірки, який закодований в початковому "розумному контрактному гаманці", розгорнутому спочатку користувачем (під час початкової UserOp). Крок перевірки може просто перевіряти підпис або виконувати більш складні операції для "надання" права на виконання UserOp. Крок перевірки обмежений op.verificationGasLimit.
  • Крок виконання: Основа UserOp, виконуючий крок виконує операцію, описану в op.callData. Цей крок також метрується, використовуючи op.callGasLimit.

Як видно з попередньої декомпозиції, етап попередньої перевірки виконується один раз, що дає можливість амортизувати витрати на попередню перевірку для всіх включених користувачів. Коли бандл виконується, всі витрати (наприклад, block.basefee + priority fee, що сплачуються бандлером блок-продюсеру, включаючи його) стягуються з бандлера, який повинен забезпечити, щоб операції користувача компенсували йому понесені витрати достатньо. Ми уточнимо ці твердження розглянемо в наступному розділі.

Модель ринку комісій за пакунки

Ми намагаємося дотримуватися класичних моделей комісійних ринків. Користувач t, який бажає виконати операцію, має деяке значення vt для виконання операції. Ми припускаємо, що всі операції мають однаковий розмір S (тобто один і той же газ, який використовується для етапів перевірки та виконання), і таким чином ми виражаємо всі величини як ціни за одиницю газу.

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

Ринок комісій EIP-1559 виставляє резервну ціну r, відому як «базова комісія», яку бандлери повинні понести, коли їхній пакет виконано. Якщо зв'язка містить n операцій, то бандлер повинен витратити не менше n × S × r. Крім того, оскільки зв'язка споживає «газ попередньої перевірки», скажімо, деяку кількість F, бандлер додатково сплачуватиме F × r

. Операції, включені в пакет, задаються множиною B.

Функції вартості пакувальника

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

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

Проблема пакувальника відображає проблему виробника блоків, виражену в[Roughgarden 2021] 3. Там блок-продюсер повинен був забезпечити надання певної цінності μ компенсувати їй витрати на включення додаткової транзакції до свого блоку (наприклад, μ може компенсувати додаткове навантаження блоку, що затримує його поширення і, таким чином, збільшує ризик реорганізації). Ринок комісій на рівні блоку повинен забезпечити, щоб блок-продюсер принаймні отримав компенсацію за загальну вартість n × S × μ, якщо блок-продюсер включив n транзакцій у свій блок. Ринок комісій на рівні бандлера вимагатиме принаймні компенсації бандлеру екзогенних витрат

Con-chain(B,r) вони несуть з великого ринку комісій, в якому вони вбудовані.

ERC-4337 пропонує можливість амортизації витрат, крім розподілу витрат на газ перед перевіркою. Якщо для всіх операцій використовується однакова схема підпису для етапу перевірки, підписи цих операцій можуть бути такими узагальнений 2від пакувальника, так що замість перевірки n підписів on-chain, може бути перевірений один підпис. У цьому випадку функція вартості пакувальника повинна враховувати витрати off-chain, які пакувальник понесе при виконанні агрегації. В подальшому ми робимо припущення, що такі витрати лінійні за кількістю операцій, подібне припущення до [Wang et al., 2024] 2, при граничних витратах ω.

Ми також враховуємо зниження споживання газу кожною операцією за рахунок економії від агрегації. При aggreGated операції не зобов'язані публікувати свій підпис, але вони вимагають додаткової операції сполучення. У мережах, де вартість calldata висока, але операції сполучення/обчислення дешеві, агрегація, таким чином, забезпечує економію на кожній операції. У цьому випадку позначаємо через S′ < S зменшений розмір угоди. Нам також потрібно врахувати збільшене попереднє використання газу F′ > F, яке тепер містить публікацію та перевірку єдиного ончейн-агрегованого підпису.

Функція агрегованої вартості: Збирач, який видає пакунок В з агрегованими підписами, коли базова плата становить r, знеходить витрату:

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

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

Перегляд кількості плати за ринок

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

Правило виділення пакетів: Виділення x (рівня пакета) вирішує набір операцій користувача, які бандлер включає до свого пакета, враховуючи поточний пул пам'яті M та базову комісію r.

Правило оплати на рівні пакета: З урахуванням обраного набору операцій B правило оплати призначає кожному включеному користувачеві плату:

Функція користувацької корисності:

В принципі, ми можемо дозволити існування правила спалювання qt(B), що виражає той факт, що пакетник не може отримати всіх включених платежів користувачів. Однак, ми не розглядаємо це в цій ноті.

(Короткозора) функція корисності бандлера:

Пакетний рівень TFM (x, p) є стимулюючим сумісним для міопічних пакувальників (MBIC), якщо, для кожного mempool M та базової плати r, міопічний пакувальник максимізує свою користь, дотримуючись рекомендації правила розподілу x (тобто встановлюючи B = x(M,r)).

Формування кількох пакунків

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

Ми можемо записати набір пакетів, які виводиться розділом x(M,β), як B(x(M,r)). Інтуїтивно ці пакети складаються з операцій, які не належать до набору з індексом 0. З урахуванням набору пакетів B, правило оплати тоді:

Функція корисності користувача перетворюється на:

і функція утиліти пакувальника стає:

Гра збирача

Включення транзакцій у блоки повинно винагороджувати деяку кількість μ виробникам блоків, яка вважається лінійною від розміру транзакції, наприклад,[Roughgarden, 2021] 3. Ця кількість позначає вартість можливості для продуцента блоків додати додаткову транзакцію до свого блоку, наприклад, збільшуючи затримку їхнього розмови та тим самим збільшуючи свої шанси на перерозподіл блоку. У Proof-of-Stake, навіть якщо графік протоколу дозволяє достатньо часу на пропагацію повного блоку, Ігри на часспровокували динаміку "останньої секунди", яка знову зробила цей параметр μ актуальним.

У будь-якому випадку, ми можемо спостерігати, що проблема розподілу вартості на рівні блоку та на рівні пакету є дуже різною. На рівні блоку транзакція не повинна знати, що ще відбувається всередині блоку, щоб розробити свою пропозицію щодо включення згідно з EIP-1559 (вона може бажати знати, що відбувається щодо MEV).[Bahrani et al., 2024] 9, але зараз ми розглянемо це як окрему проблему). На рівні пакетів витрати на надбудову бандла більше не лінійні залежно від кількості транзакцій, але фіксовані витрати можуть бути амортизовані великою кількістю транзакцій. Крім того, якщо вартість агрегації операцій користувача не лінійна залежно від кількості транзакцій (наприклад, деякі докази фактично підлінійні за розміром, що доводяться), є можливість амортизувати загальну вартість серед багатьох користувачів.

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

• op.maxPriorityFeePerGas та op.maxFeePerGas можуть бути встановлені відповідно до евристики, яку користувач використовував би відповідно до EIP-1559, тобто, враховуючи деяку приблизну кількість газу, який він планує споживати, користувач повинен встановити ці атрибути, щоб відкалібрувати, скільки він готовий заплатити в найгіршому випадку (maxFee) і скільки він готовий поповнити, щоб заплатити кінцевому виробнику блоку (maxPriority). Але як оцінювати газ користувачеві?
• op.preVerificationGas - це атрибут UserOperation, який повинен бути встановлений для вказівки кількості «додаткового газу», який планує використати операція користувача. В нашій моделі ми дозволяємо
• F позначають це «фіксовані газові накладні витрати». Якщо в пакет включено n користувачів, кожен користувач повинен встановити preVerificationGas = F / n. Однак, якщо користувач готує свою операцію з урахуванням найгіршого сценарію, він повинен встановити preVerificationGas = F.

Таким чином, preVerificationGas є основним вектором, за допомогою якого користувачі опосередковують свою ставку та намагаються врахувати амортизацію витрат бандлером. Припустимо, що n користувачів приходять на ринок зі своїми операціями, і всі вони переконані бандлером зробити ставку в найгіршому випадку, залишившись один у пакеті. Ми також припустимо, що користувачі встановлюють свій maxPriorityFeePerGas на нуль заради цього прикладу. Тоді всі ці n користувачів встановлюють preVerificationGas = F, і бандлер може вивести пакет, винагороджуючи їх за допомогою:

при цьому вони повинні понести витрати:

одного разу вони публікують пакет, упаковуючи всі операції разом в блок. Це приносить бандлеру прибуток π = (n−1)×F×r.

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

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

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

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

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

Ідеальний варіант: витрати розподіляються між користувачами у пакеті. Песимістичний варіант: користувачі переплачують, а витрати не розподіляються.731×755 77,6 КБ

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

Аліса очікує, що крім неї з'являться ще 9 користувачів, і тому вона встановлює свій preVerificationGas на 1, як вона знає, F = 10. Цінність Аліси та цінності всіх інших користувачів сумісна з тим, що вони встановлюють preVerificationGas = 3, але вона намагається заплатити найменшу можливу суму за її включення. Як з'ясувалося, на ринку з'являється лише 5 користувачів, які також встановили свій preVerificationGas на 1. Бандлер не отримає компенсацію за F = 10 одиниць газу, таким чином, бандлер не видає зв'язку, а користувачі отримують 0 утиліт. Це, очевидно, неоптимально, оскільки, наприклад, користувачі могли встановити preVerificationGas = 2 і отримати 1 утиліту (максимум preVerificationGas, який вони були готові встановити, мінус фактичний preVerificationGas, за включення якого вони заплатили).

Майбутня робота

Як показує гра бандлера, з проблемою розподілу стикається користувач, який бажає бути включеним до складу бандлера. У наступній примітці ми розглянемо різні підходи до відновлення «хорошого UX» для користувача, щоб запобігти переплаті бандлеру, який краще поінформований про попит на його пакетну ємність. Наступне дослідження вимагатиме розуміння структури ринку, що зв'язує користувачів, бандлерів та виробників/виробників блоків разом.

Застереження:

1. Цю статтю перепубліковано з [ethresear], Усі авторські права належать оригінальному автору [Давіде Реззолі]. Якщо є заперечення проти цього перепублікування, будь ласка, зв'яжіться з Gate Learn команди, і вони оперативно впораються з цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.