Como as taxas de user operation são estimadas e cobradas

Em nossa série de posts sobre estimativa de gas do ERC-4337, começando com como funciona a estimativa de gas do ERC-4337, discutimos o passo 2 do “User Operation Flow”, eth\_estimateUserOperationGas, e suas complicações, incluindo o problema de transferência de gas token e os desafios de estimar gas em L2. Este post vai focar no passo 3 do fluxo, detalhando como as taxas de gas são estimadas e cobradas.

Para os fins deste post, vamos assumir que estamos trabalhando com uma chain que suporta EIP-1559. O entendimento do EIP-1559 é conhecimento prévio necessário para compreender os campos de taxa em uma user operation.

User operations têm os mesmos campos de taxa que transações EIP-1559:

• maxFeePerGas: o valor total máximo que um usuário oferece para pagar (base fee + priority fee)
• maxPriorityFeePerGas: a priority fee máxima ou “gorjeta” que o usuário oferece

O entry point usa a seguinte fórmula para calcular o gas price resultante a partir desses dois campos:

Como você pode ver, maxFeePerGas atua como um teto absoluto para o gas price, enquanto maxPriorityFeePerGas atua como uma gorjeta sobre a base fee do bloco.

Bundle transactions

Quando bundlers enviam bundle transactions para o entry point, eles também estão sujeitos a um gas price derivado das dinâmicas do EIP-1559. Bundlers definem um maxFeePerGas e um maxPriorityFeePerGas. O gas price final é calculado a partir desses valores e da base fee do bloco em que a transação é incluída.

Bundlers enviam uma transação a um gas price, e depois são compensados a um gas price, potencialmente diferente, definido por cada user operation no bundle. Se o gas price da user operation for mais alto, o bundler lucra; caso contrário, o bundler tem prejuízo nessa user operation. O maxPriorityFeePerGas não é apenas uma gorjeta para o bundler, também ajuda o bundler a se compensar pela gorjeta que teve que pagar ao block builder para conseguir a inclusão da bundle transaction (a menos que o bundler seja ele próprio um builder).

Como os bundlers são incentivados financeiramente?

Fazer bundling pode ser uma tarefa cara, principalmente devido às simulações complexas necessárias para garantir a segurança do bundler. Para permitir que os bundlers recuperem esses custos computacionais, e para incentivar um mercado saudável para user operations (o que melhora a UX ao reduzir o tempo até a inclusão), é necessário que existam incentivos financeiros para os bundlers na forma de receita excedente.

Essa receita pode assumir múltiplas formas: priority fees, MEV e acordos off-chain.

1. Priority fees

Bundlers podem exigir que os senders incluam em suas operations uma priority fee maior do que a priority fee que o bundler pagou em sua transação. Senders que querem melhorar suas chances de serem incluídos em um bundle durante períodos de alta congestão podem aumentar o valor ofertado de priority fee.

2. Receita de MEV

Bundlers podem extrair MEV das operations no mempool, já que têm direitos de ordenação no bundle. Eles são livres para fazer back-run e sandwich em operations para embolsar esse lucro.

3. Off-chain

Bundlers podem rodar mempools privados (com recursos como proteção contra MEV) e fazer acordos off-chain com os senders de user operations. As taxas seriam garantidas por algum mecanismo off-chain.

Para garantir uma rede saudável, argumentamos que (1) é uma opção necessária para a maioria das user operations.

MEV positivo não está disponível para extração em todo tipo de user operation. Se dependermos apenas desse incentivo, os bundlers não vão pegar a maioria das user operations. Acordos off-chain são centralizadores e muitos usuários vão querer evitar esse vetor. Isso deixa as Priority Fees.

O Rundler da Alchemy atualmente define uma priority fee dinâmica exigida para o bundling. Essa taxa é baseada nas taxas de rede estimadas no momento. Se uma user operation oferece menos que a taxa de rede estimada, mais uma pequena gorjeta de overhead para o bundler, ela não será incluída em um bundle e ficará no mempool.

Como os bundlers estimam as taxas de gas?

Antes do bundling, o bundler deve realizar sua própria estimativa das taxas que vai submeter para garantir a inclusão da bundle transaction através do bundle marketplace. Normalmente um bundler vai construir para inclusão no próximo bloco, e vai ofertar um preço razoável para garantir a inclusão.

Para estimar base fees, o bundler pode consultar a rede para obter a base fee do bloco atual. Normalmente é desejável adicionar pelo menos 25% de overhead (o valor máximo que a taxa pode aumentar nos próximos 2 blocos) para garantir que a transação não fique travada.

Para estimar a priority fee, o bundler pode usar eth\_maxPriorityFeePerGas. Assim como com a base fee, é desejável adicionar uma porcentagem de overhead para garantir que a transação seja incluída.

Com essas taxas estimadas, o bundler pode então consultar o mempool e filtrar as user operations que ofertaram o suficiente para serem incluídas (incluindo a pequena “gorjeta” do bundler).

Como os senders devem estimar as taxas de user operation?

No lado do cliente, os senders devem estimar as taxas necessárias para o bundling. Se estimarem baixo demais, sua user operation pode ficar travada no mempool. Se estimarem alto demais, especificamente para a priority fee, podem acabar pagando a mais pela inclusão.

Recomendamos a seguinte abordagem ao interagir com o Rundler antes da rede p2p:

1. Estime a base fee. Adicione um overhead com o qual você esteja confortável para garantir a inclusão caso o preço se mova contra você. Recomendamos pelo menos 25%.
2. Estime a priority fee usando eth\_maxPriorityFeePerGas. Adicione um overhead com o qual você esteja confortável. Recomendamos pelo menos 10%
3. Adicione o overhead de “gorjeta” do bundler, dependente da rede, à priority fee.
4. Some a priority fee à base fee para obter maxFeePerGas, maxPriorityFeePerGas é a taxa estimada do passo 2.

Estimativa de taxas na Arbitrum

O sequencer da Arbitrum ignora priority fees e eth\_maxPriorityFeePerGas sempre retorna 0. Para compensar o bundler, exigimos uma priority fee que seja uma porcentagem fixa da max base fee estimada do bundler. Atualmente cobramos 5%.

Estimativa de taxas na Optimism

A Optimism tem um caso extremo, descrito em nosso post anterior sobre estimativa de gas em L2, que impacta a estimativa de taxas.

Na Optimism, definimos maxPriorityFeePerGas = l1\_gas / l2\_base\_fee. No entanto, como em uma transação normal da Optimism as priority fees se aplicam apenas ao componente de gas da L2, elas podem ser ordens de magnitude maiores que a base fee da L2. Por isso, exigimos que a priority fee de um bundle seja uma porcentagem fixa da base fee estimada. Atualmente cobramos 5%

Mempool P2P

Assim que o mempool P2P estiver funcionando, vai surgir um mercado separado para taxas de user operation. Isso pode simplificar substancialmente a estimativa de taxas para user operations. Em vez de rodar cálculos estáticos para a priority fee como descrito acima, o usuário pode usar o histórico de taxas para estimar sua oferta. Não importa mais o critério que um único bundler está usando para escolher user operations, apenas que algum bundler veja uma user operation como valiosa o suficiente para incluir em um bundle.

O Rundler vai suportar um método rundler\_userOperationFeeHistory (ou algo parecido, que poderia ser padronizado) similar ao eth\_feeHistory, que os usuários podem consultar para estimar suas ofertas com base em operations incluídas em bundles anteriormente.

🦀

Continue lendo

Se você perdeu os três primeiros artigos desta exploração técnica sobre estimativa de gas do ERC-4337, veja como funciona a estimativa de gas do ERC-4337 e como superamos complicações para fornecer estimativas de gas precisas para user operations.

• Como Funciona a Estimativa de Gas do ERC-4337
• Dummy Signatures e Gas Token Transfers
• L2 Gas e Signature Aggregators