В статье рассматриваются преимущества native rollups при выполнении на L1, особенно в контексте проблем с оплатой газа. Отмечается, что благодаря внедрению новых функций, таких как blob sharing, затраты на data availability (DA) можно более эффективно контролировать, а все вызовы native rollup используют единую функцию исполнения, что стандартизирует затраты на выполнение. Кроме того, затраты на proof включаются в расходы на исполнение, благодаря чему оплата газа native rollups ожидается на уровне оплаты газа L1. Для non-native rollups, основанных на децентрализованных sequencers, в статье предлагаются различные стратегии адаптации, включая максимальное использование FOCIL и механизмов pre-confirmation, фильтрацию недостаточно оплаченных транзакций и избегание превращения в native rollups.

Что касается учёта газа, эта проблема возникает у rollups из-за их необходимости распределять батчи по блокам L1 и самостоятельно управлять затратами. В будущем с native rollup учёт газа может быть значительно проще:
<ol>
<li>По затратам на DA: с появлением таких функций, как blob sharing, а также с возрастанием количества blob и rollups, можно будет считать, что blob заполняются полностью, а стоимость DA на байт транзакций внутри blob одинакова. Таким образом, можно будет включить плату за DA на транзакцию внутрь blob.</li>
<li>Все native rollups вызывают одну и ту же функцию исполнения, что должно стандартизировать издержки исполнения для всех rollups и их транзакций. При этом расширения или производные функции rollup могут создавать небольшие дополнительные накладные расходы, но они будут представлять собой незначительные постоянные величины на батч или вычисляемые множители на транзакцию.</li>
<li>Затраты на верификацию уже включены в издержки исполнения в этом будущем native rollup.</li>
</ol>
В целом, это означает, что учёт газа для транзакций native rollup имеет реальную перспективу стать эквивалентным учёту газа на уровне L1.
Основные проигравшие в таком сценарии — это выделенные sequencer rollups, не основанные на native, которые предлагают preconfirmations. Если нельзя внедрить учёт газа, аналогичный тому, что применяется в текущих централизованных sequencer rollups, есть несколько вариантов:
<ol>
<li>Максимально использовать FOCIL и inclusion preconfirmations.</li>
<li>Ввести механизм фильтрации транзакций с недостаточной оплатой газа в случае изменения затрат, вызванного пропущенным слотом L1, то есть при полном или частичном реорганизовании предварительно подтверждённой цепочки.</li>
<li>Отказаться от native подхода.</li>
</ol>

Краткий обзор преимуществ и проблем, связанных с оплатой газа при нативном исполнении на L1