Уровень 2 Native Токены как Оплата Транзакционных Платежей: Технический анализ

Эта техническая статья рассматривает преимущества и недостатки разрешения пользователям оплачивать транзакционные сборы с помощью нативных токенов Уровня 2, анализируя как технические механизмы, так и рыночные последствия.

Предварительные требования

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

Введение

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

Техническая заметка: Объективная проверка "корректной публикации данных" представляет собой значительные трудности, что затрудняет внедрение эффективных механизмов наказания. Это вызывает вопросы о целесообразности конструкций, которые полагаются на "стейкинг L2 токенов для функциональности публикации данных."

Платеж комиссии за нативный токен: технический и рыночный анализ

Технические преимущества

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

Технические ограничения

Вызов деноминации стоимости данных

Основная проблема заключается в том, что Sequencers Rollup должны оплачивать затраты на доступность данных в нативной валюте L1 (ETH) при загрузке данных транзакций в Ethereum. Это создает неявный риск обменного курса между моментом, когда Sequencer получает токены L2 в качестве оплаты, и моментом, когда они должны конвертировать эти токены в ETH для покрытия затрат на доступность данных. Эта подверженность рискам добавляет операционную сложность для операторов Sequencer.

Техническая заметка: Эта проблема выходит за рамки Rollups на базе Ethereum. Сети Уровня 2, использующие альтернативные слои доступности данных (, такие как Mantle или Manta), сталкиваются с аналогичными проблемами, связанными с родным токеном соответствующего слоя DA.

Влияние на пользовательский опыт

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

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

Техническая заметка: Хотя Polygon PoS технически является сайдчейном, а не настоящим Уровнем 2, этот пример эффективно иллюстрирует проблему пользовательского опыта.

Это трение умножается по всей экосистеме - с N различными сетями уровня 2, требующими N различных токенов для основных операций.

Препятствия к межсетевой совместимости Уровня 2

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

Это заставляет пользователей управлять несколькими токенами и преодолевать сложные проблемы с ликвидностью. С N различными Уровень 2 ликвидность фрагментируется по N-1 токен парам, что требует от пользователей выполнения N различных обменов перед работой в нескольких L2 средах. Более сложные кросс-L2 операции, такие как кредитование, открытие позиций и ликвидации, сталкиваются с нарастающим трением из-за этих требований к токенам за транзакции.

Видение суперцепи Optimism для интероперабельности идеально иллюстрирует эту проблему - если каждый Rollup в экосистеме суперцепи требует разные токены для оплаты сборов, это напрямую подорвет основные цели интероперабельности.

Однако эти ограничения в опыте и взаимодействии применимы только к эксклюзивным моделям сборов на основе нативных токенов. Гибридные подходы, которые поддерживают как платежи в 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.

Секвенсоры транзакций (майнеры, валидаторы или Уровень 2 секвенсоры) сохраняют право включать или исключать конкретные транзакции. Однако, после включения, транзакции могут быть оплачены только в пределах максимальной комиссии, указанной пользователем.

Анализ реализации Oracle

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

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

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

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

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

Требования к механизму принудительного включения

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

Если эти протоколы Уровня 2 реализуют платежи за комиссии в родных токенах, механизмы Force Inclusion сталкиваются с критической технической проблемой: как справедливо определить комиссии ETH на L1 за транзакции, которые обычно стоили бы токены L2? Без точных обменных курсов это может как несправедливо наказать пользователей Force Inclusion чрезмерными сборами, так и позволить злоумышленникам воспользоваться искусственно низкими сборами.

Этот конкретный сценарий представляет собой убедительный пример использования интеграции оракулов - позволяя контрактам L1 справедливо рассчитывать сборы за транзакции принудительного включения.

В качестве альтернативы, протоколы Уровня 2 могут стандартизироваться на своих собственных токенах как для регулярных, так и для транзакций Force Inclusion, устраняя необходимость в конверсии между валютами. Однако затраты на доступность данных остаются номинированными в ETH, создавая гибридную модель сборов, где транзакции Force Inclusion требуют как ETH ( за данные ), так и токены Уровня 2 ( за выполнение ) - техническая проблема, которую разработчики Уровня 2 должны решить при реализации моделей сборов с использованием собственных токенов.

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

• Токены уровня 2 могут выполнять несколько технических функций, причем оплата сборов представляет собой значительное расширение полезности за пределами управления.

• Основное преимущество моделей оплаты с использованием нативных токенов заключается в установлении четкой полезности токенов с потенциальными дефляционными механизмами через реализацию EIP-1559.

• Технические недостатки включают повышенный риск для секвенсора, трение в пользовательском опыте и барьеры совместимости в экосистеме Уровень 2.

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

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

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

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

• Реализации Force Inclusion с платой в нативных токенах создают сложные технические проблемы, потенциально требуя от пользователей платить как ETH ( за доступность данных ), так и токены L2 ( за сборы за выполнение ) в одной транзакции.