Механизмы комиссий за транзакции стали рабочими лошадками для понимания посредничества производителей блоков между пользователями, желающими совершить транзакцию, и «цепочкой» (или «протоколом»), по которой пользователи совершают транзакции. Учитывая возможность использовать часть предложения, предоставляемого цепочкой, производители блоков должны решать, какие пользователи будут иметь возможность использовать ограниченный ресурс исполнения в цепочке и какой ценой. В Ethereum из-за вопроса стоимости производители блоков ограничены механизмом комиссий EIP-1559, который динамически устанавливает резервную цену от блока к блоку, называемую «базовой комиссией». Базовая комиссия — это цена, выраженная за единицу газа, которую должна заплатить пользовательская транзакция, чтобы быть включенной и выполненной. Пользователь может предоставлять так называемые «приоритетные сборы» сверх базовой платы, чтобы дополнительно стимулировать производителей блоков во время перегрузки.

В этой заметке мы рассматриваем вопрос встроенных рынков комиссий, т.е. рынков комиссий, которые "живут" в пределах других рынков комиссий. Этот вопрос обсуждался в другом контексте в недавней статье Марьям Бахран, Пранава Гаримиди и Тима Рафгардена, "Gate"Дизайн механизма комиссии за транзакции в мире после MEV 9”. В этой статье авторы моделируют использование поисковиков, дополнительно посредничая доступ к цепочке между пользователями и производителями блоков. Производители блоков получают «подсказки» от поисковиков, воплощенные в виде атомных пакетов транзакций, которые должны быть включены в цепочку. Рынок оплаты поисковиков определяется максимизационной целью величины, известной как MEV или максимально извлекаемая ценность.

В нашей настройке пользователи хотят получить доступ к цепочке, но не выражают свои требования с помощью транзакций, читаемых протоколом. Вместо этого пользователи создают «операции», которые объединяются сущностями, известными как «упаковщики», которые затем инициируют транзакцию, читаемую протоколом, упаковывая операции вместе для выполнения. Таким образом, с точки зрения механизма комиссий EIP-1559, бандлеры являются пользователями цепочки, но фактические пользователи должны сначала получить включение в пакет бандлера, прежде чем они смогут получить включение в цепочку. Другими словами, мы можем рассматривать эту настройку как часть более широкого вопроса о совместное создание блоков, который возникает с (частичными) строителями/поисковиками, а также списками включений.

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

Для исследования различий между прямыми комиссионными рынками и их встроенными (под-)механизмами необходимо определить экономические ограничения, которым подчиняется пакетировщик. В следующем разделе мы предлагаем простую модель функции стоимости пакетировщика, мотивированную практикой, в частности, пакетировщиками, участвующими в протоколе ERC-4337, который мы кратко рассмотрим.

Модель

Связывание в ERC-4337

Пользователь, желающий выполнить какую-либо операцию в цепочке с помощью связующих элементов, выполняет пользовательскую операцию (UserOp или операцию). Эта UserOp передается из кошелька пользователя, например, после взаимодействия с DApp. После трансляции UserOp некоторый связующий элемент, получивший операцию, может решить включить ее в пакет. Пакет представляет собой метатранзакцию «внешнеобладаемого аккаунта» (EOA), которая записывает данные включенных UserOps в свое поле bundle.calldata. Связующий элемент отправляет пакет для включения в блок производителем блоков (мы рассмотрим связь между связующим элементом и производителем блоков в будущей заметке).

Однажды пакет включается в блок, и блок попадает в цепочку, пакет выполняется вместе с другими транзакциями в блоке. По существу, шаги выполнения пакета следующие:

• Предварительная проверка: транзакция EOA бандлера потребует 21 000 газа, и вызов контракта EntryPoint настроит ключевые переменные для отслеживания выполнения операций в цикле операций.
• Операция петля 3: Для каждой операции, включенной в пакет, происходят следующие два шага:
  • Шаг проверки: Пользовательские операции выполняют операции, содержащие шаг проверки, который закодирован в «умном контракте кошелька», развернутом изначально пользователем (во время первоначальной UserOp). Шаг проверки может просто проверять подпись или выполнять более сложные операции для «предоставления» права UserOp на продолжение выполнения. Шаг проверки метрируется op.verificationGasLimit.
  • Шаг выполнения: Ядро UserOp, шаг выполнения выполняет операцию, описанную в op.callData. Этот шаг также измеряется с использованием op.callGasLimit.

Как ясно из предыдущего разложения, этап предварительной проверки выполняется один раз, что позволяет амортизировать затраты на предварительную проверку по всем включенным пользователям. При выполнении пакета все затраты (например, block.basefee + приоритетные комиссии, уплаченные пакетировщиком блоку производителя, включая их) оплачиваются пакетировщиком, который должен обеспечить компенсацию затрат пользователями на его операции. Мы формализуем эти утверждения в следующем разделе.

Модель рынка комиссий для пакетов

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

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

Рынок комиссий EIP-1559 устанавливает резервную цену r, известную как «базовая комиссия», которую должны понести связующие при выполнении своего пакета. Если пакет содержит n операций, связующий должен затратить как минимум n × S × r. Кроме того, поскольку пакет потребляет «предварительный газ для проверки», скажем, некоторое количество F, связующий также заплатит F × r.

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

Функции стоимости пакетов

Теперь мы рассматриваем затраты, понесенные пакетировщиками при включении их пакетов в блок.

Функция стоимости на цепочке: Бандлер, выпуская пакет B, когда базовая комиссия составляет r, тратит стоимость:

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

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

ERC-4337 предоставляет возможность амортизировать затраты, выходящие за рамки распределения затрат на газ предварительной проверки. Если все операции используют одну и ту же схему подписи для шага проверки, подписи этих операций могут быть собранных 2 сборщиком, так что вместо проверки N подписей в цепочке может быть проверена одна подпись. В этом случае функция стоимости сборщика должна будет учитывать затраты вне сети, которые сборщик несет при выполнении агрегирования. Далее мы делаем предположение, что такие издержки линейны по числу операций, аналогично предположению [Wang et al., 2024] 2, по предельной стоимости ω.

Мы также учитываем снижение потребления газа на каждой операции за счет экономии за счет агрегации. При агрегировании операции не обязаны публиковать свою подпись, но для них требуется дополнительная операция сопряжения. В цепочках, где стоимость calldata высока, а операции сопряжения/вычисления дешевы, агрегация, таким образом, обеспечивает экономию на каждой операции. В этом случае обозначим через S′ < S уменьшенный размер транзакции. Нам также необходимо учитывать возросшее использование газа для предварительной проверки F′ > F, который теперь содержит публикацию и проверку единой агрегированной подписи в сети.

Функция агрегированной стоимости: Бандлер, выдающий пакет B с агрегированными подписями, когда базовая плата составляет 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, правило оплаты будет следующим:

Функция полезности пользователя становится:

и функция утилиты пакетов становится:

Игра в упаковщика

Включение транзакций в блоки должно вознаграждать некоторое количество μ производителям блоков, которое предполагается линейным от размера транзакции в, например, [Рафгарден, 2021] 3. Это количество обозначает издержки для производителя блока при добавлении дополнительной транзакции в свой блок, например, увеличение задержки передачи сообщений и тем самым увеличение вероятности реорганизации блока. В доказательстве доли, хотя протокол позволяет достаточно времени для полной передачи блока, игры по временииндуцированные «последними секундами» динамики распространения снова сделали этот параметр μ актуальным.

В любом случае, мы можем заметить, что проблема распределения затрат на уровне блока и на уровне пакета очень разная. На уровне блока транзакция не обязана знать, что еще происходит внутри блока, чтобы определить свою ставку на включение согласно 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 операций вместе в блок. Это приносит прибыль бандлеру π = (n−1)×F×r.

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

На первом этапе пользователи отправляют свои операции, которые фиксируются их атрибутами, такими как preVerificationGas. На втором этапе пакетировщик, получив все транзакции пользователей, решает выдать пакет или набор пакетов. Интересно, что даже если пользователи знают, сколько других пользователей будет участвовать на первом этапе, то есть, даже если n является общим знанием для всех пользователей, пакетировщик может заставить пользователей установить наихудший случай preVerificationGas = F, угрожая играть

, т. е. угрожая держать каждого пользователя в их собственном отдельном пакете и взимать с них максимальное количество газа F.

Обратите внимание, что эта угроза может быть недостоверной, так как пользователи ожидали бы, что пакетизатор предпочтет играть

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

Идеальный случай: расходы делятся между пользователями в пакете. Пессимистический случай: пользователи переплачивают, и расходы не делятся.731×755 77.6 KB

Расширение этой модели может рассматривать байесовский случай, когда пользователи имеют доступ к распределению по n, т. е. они могут предвидеть, что n пользователей появятся в любой момент времени в соответствии с каким-то распределением (например, Пуассоновские появления), даже если они заранее не знают результат случайной величины. Это может привести к неэффективным результатам, как показывает следующий пример:

Алиса ожидает, что помимо нее появятся еще 9 пользователей, поэтому она устанавливает preVerificationGas равным 1, так как она знает, что F = 10. Ценность Алисы и всех остальных пользователей совместима с тем, что они устанавливают preVerificationGas = 3, но она пытается заплатить как можно меньшую сумму за свое включение. Как выясняется, на рынке появляется только 5 пользователей, которые также установили свой preVerificationGas на 1. Сборщик не будет компенсирован за F = 10 единиц газа, таким образом, сборщик не выводит связку, а пользователи получают 0 полезности. Очевидно, что это неоптимально, так как все пользователи могут установить preVerificationGas = 2, например, и получить 1 utility (максимальный preVerificationGas, который они готовы установить, за вычетом фактического preVerificationGas, за который они заплатили).

Будущая работа

Как показывает игра бандлера, у пользователя, желающего быть включенным бандлером, возникает проблема выделения. В следующей заметке мы рассмотрим различные подходы к восстановлению «хорошего пользовательского опыта» для пользователя, чтобы предотвратить их переплату бандлеру, который лучше осведомлен о спросе на его возможности для пакетов. Следующее исследование потребует понимания структуры рынка, объединяющей пользователей, бандлеров и строителей/блок-производителей.

Disclaimer:

1. Эта статья взята из [Gate]ethresear], Все авторские права принадлежат оригинальному автору [DavideRezzoli]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в данной статье, являются исключительно мнениями автора и не являются инвестиционными рекомендациями.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиатство переведенных статей запрещено.