Os mecanismos de taxas de transação tornaram-se os modelos de cavalo de batalha para entender a intermediação dos produtores de blocos entre os usuários que desejam transacionar e "a cadeia" (ou "o protocolo") na qual os usuários transacionam. Dada a capacidade de usar parte do suprimento fornecido pela cadeia, os produtores de blocos devem arbitrar quais usuários terão capacidade de usar o recurso escasso da execução on-chain e a que custo. No Ethereum, para a questão do custo, os produtores de blocos são limitados pelo mecanismo de taxa EIP-1559, que define dinamicamente um preço de reserva bloco a bloco, chamado de "taxa base". A taxa base é um preço, expresso por unidades de gás, que uma transação do usuário deve pagar para ser incluída e executada. O usuário pode fornecer as chamadas "taxas prioritárias" além da taxa base, para incentivar ainda mais os produtores de blocos em tempos de congestionamento.

Nesta nota, investiGate a questão dos mercados de taxas incorporadas, ou seja, mercados de taxas que “vivem” dentro de outros mercados de taxas. Essa questão foi discutida em um contexto diferente em um artigo recente de Maryam Bahrani, Pranav Garimidi e Tim Roughgarden,Mecanismo de Taxa de Transação em um Mundo Pós-MEV 9”. Neste artigo, os autores modelam o uso de buscadores, intermediando ainda mais o acesso à cadeia entre usuários e produtores de blocos. Os produtores de blocos recebem "dicas" de buscadores, incorporadas por pacotes atômicos de transações a serem incluídos pela cadeia. O mercado de taxas dos buscadores é impulsionado pelo objetivo de maximização de uma quantidade conhecida como MEV, ou valor máximo extraível.

Em nosso ambiente, os usuários desejam acessar a cadeia, mas não expressam sua demanda usando transações legíveis por protocolo. Em vez disso, os usuários produzem “operações”, que devem ser agrupadas por entidades conhecidas como “agrupadores”, que então originam uma transação legível por protocolo empacotando as operações juntas para a execução. Assim, para o mecanismo de taxa EIP-1559, os agrupadores são os usuários da cadeia, mas os usuários reais devem primeiro obter a inclusão no agrupamento de um agrupador antes de poderem obter a inclusão na cadeia. Em outras palavras, podemos ver esse cenário como parte da questão maior de co-criação de blocos, que surge com (parcial) construtores/pesquisadores, assim como listas de inclusão.

Nossa esperança é que essas dinâmicas sejam o mais transparentes possível, de forma que não haja mais sobrecarga cognitiva ou oportunidades para o usuário ser indevidamente explorado pelo agrupador, em comparação com a realização direta na cadeia. Esperamos resultados ainda mais fortes, casos em que de fato os usuários se beneficiem da intermediação do agrupador, quando os custos amortizados permitirem que os usuários desfrutem de maior bem-estar.

Para investigar a distinção entre os mercados de taxas diretas e seus (sub)mecanismos embutidos, precisamos precisar as restrições econômicas que um empacotador respeita. Na seção seguinte, oferecemos um modelo simples da função de custo do empacotador motivado pela prática, em particular os empacotadores participantes do protocolo ERC-4337, que recapitulamos brevemente.

Modelo

Agrupando em ERC-4337

Um usuário que deseja realizar alguma atividade on-chain via bundlers emite uma Operação do Usuário (UserOp, ou operação). Esta UserOp é emitida da carteira do usuário, por exemplo, após interagir com um DApp. Uma vez que a UserOp é transmitida, algum bundler que recebe a operação pode decidir incluí-la em um pacote. Um pacote é uma meta-transação de “conta de propriedade externa” (EOA), que escreve os dados das UserOps incluídas em seu campo de bundle.calldata. O bundler emite o pacote para inclusão em um bloco por um produtor de blocos (discutiremos a relação entre bundler e produtor de blocos em uma nota futura).

Uma vez que o pacote é incluído no bloco, e o bloco segue para a cadeia, o pacote é executado juntamente com outras transações no bloco. Essencialmente, as etapas de execução do pacote são as seguintes:

• Pré-verificação: A transação EOA de um bundler consumirá 21.000 gas, e a chamada ao contrato EntryPoint configurará variáveis-chave para acompanhar a execução das operações no loop de operação.
• Operação loop 3: Para cada operação incluída no pacote, os seguintes dois passos são realizados:
  • Etapa de verificação: UserOps realizam operações contendo uma etapa de verificação, que é codificada em uma "carteira de contrato inteligente" implantada inicialmente pelo usuário (durante um UserOp inicial). A etapa de verificação pode simplesmente verificar uma assinatura, ou realizar operações mais complexas para "conceder" o direito para o UserOp proceder com sua execução. A etapa de verificação é medida pelo limite de gás de verificação da op.
  • Etapa de execução: O núcleo do UserOp, a etapa de execução realiza a operação descrita em op.callData. Esta etapa também é medida, usando op.callGasLimit.

Como fica claro pela decomposição anterior, a etapa de pré-verificação é executada uma vez, oferecendo a possibilidade de amortizar os custos de pré-verificação entre todos os usuários incluídos. Quando o pacote é executado, todos os custos (por exemplo, block.basefee + taxas de prioridade pagas pelo agrupador ao produtor de bloco que as incluiu) são cobrados do agrupador, que deve garantir que as operações do usuário a compensem o suficiente pelos custos incorridos. Fazemos essas afirmações precisas na seção a seguir.

Modelo de mercado de taxas para pacotes

Nós tentamos permanecer consistentes com modelos clássicos de mercados de taxas. Um usuário t que deseja emitir uma operação tem algum valor vt para a execução da operação. Assumimos que todas as operações têm o mesmo tamanho S (ou seja, mesmo gás usado para as etapas de verificação e execução), e assim expressamos todas as quantidades como preços por unidade de gás.

Os usuários expressam seu desejo de serem incluídos emitindo um lance bt junto com sua operação. Por enquanto, não assumimos uma gramática específica para o usuário expressar seu lance de inclusão, por exemplo, a capacidade de expressar uma taxa máxima e uma taxa de prioridade junto com sua operação, como fariam com o EIP-1559. As operações do usuário são coletadas em um mempool M, representando o status pendente dessas operações até a inclusão.

O mercado de taxas EIP-1559 expõe um preço de reserva r conhecido como “taxa base”, que os agrupadores devem incorrer quando seu pacote é executado. Se o pacote contém n operações, o agrupador deve então gastar pelo menos n × S × r. Além disso, como o pacote consome “gás de pré-verificação”, digamos, alguma quantidade F, o agrupador pagará adicionalmente F × r.

. As operações incluídas no pacote são dadas pelo conjunto B.

Funções de custo do Bundler

Agora consideramos os custos incorridos pelos agrupadores para a inclusão de seus pacotes no bloco.

Função de custo on-chain: Um agrupador emite o pacote B quando a taxa base é r, incorrendo em um custo:

O problema do agrupador de transações espelha o problema do produtor de blocos expresso em[Roughgarden 2021] 3. Lá, o produtor de bloco teve que garantir o fornecimento de algum valor μ compensando-a pelo custo de incluir uma transação adicional em seu bloco (por exemplo, μ pode compensar a carga extra do bloco, que atrasa sua propagação e aumenta assim o risco de reorganização). O mercado de taxas de bloco deve então garantir que o produtor de bloco seja pelo menos compensado pelo custo total n × S × μ, caso o produtor de bloco inclua n transações em seu bloco. O mercado de taxas de agrupador exigirá compensar pelo menos o agrupador por custos exógenos.

Con-chain(B,r) incorrem na taxa de mercado maior em que estão inseridos.

ERC-4337 oferece a possibilidade de amortizar custos além de compartilhar os custos de gás de pré-verificação. Se todas as operações empregarem o mesmo esquema de assinatura para sua etapa de verificação, as assinaturas dessas operações podem seragregado 2pelo agrupador, de modo que em vez de verificar n assinaturas on-chain, uma única assinatura pode ser verificada. Neste caso, a função de custo do agrupador precisará levar em conta os custos off-chain que o agrupador incorre ao realizar a agregação. A seguir, fazemos a suposição de que esses custos são lineares em relação ao número de operações, uma suposição semelhante a [Wang et al., 2024] 2, a um custo marginal ω.

Também consideramos o consumo reduzido de gás de cada operação, devido às economias da agregação. Quando agregadas, as operações não precisam publicar sua assinatura, mas precisam de uma operação de emparelhamento adicional. Em cadeias onde o custo de calldata é caro, mas as operações/de computação de emparelhamento são baratas, a agregação fornece economia por operação. Nesse caso, denotamos por S' < S o tamanho reduzido de uma transação. Também precisamos considerar o aumento do uso de gás de pré-verificação F' > F, que agora contém a publicação e verificação da única assinatura agregada na cadeia.

Função de custo agregado: Um agrupador que emite o pacote B com assinaturas agregadas quando a taxa base é r gasta um custo:

Nesta nota, não iremos mais adiante, mas também se pode considerar os custos de publicação dos dados que um agrupador pode precisar gastar quando seu agrupamento se estabiliza em um rollup. Sugerimos duas maneiras de modelar isso e deixamos esta pergunta para trabalhos futuros:

• Ou o próprio empacotador é responsável pela publicação de dados (por exemplo, como um sequenciador) e, portanto, exige obter dos usuários a quantidade necessária de fundos para pagar eventuais custos de publicação de dados.
• Ou o mercado de taxas de nível de pacote está embutido em um mercado de taxas de nível de lote maior, através do qual o rollup expõe aos usuários do rollup (incluindo o empacotador) a quantidade que eles precisam pagar devido à congestão (por exemplo, uma taxa base) e os custos futuros de publicação de dados. Nesse caso, o rollup é responsável por equilibrar seus próprios custos futuros com suas receitas presentes.

Revisitando quantidades do mercado de taxas

Agora podemos expressar formalmente os conceitos relevantes para o mercado de taxas ao nível do pacote, derivando-os de forma direta da literatura anterior, levando em consideração a incorporação.

Regra de alocação do nível do pacote: Uma alocação (de nível de pacote) x decide o conjunto de operações do usuário que o agrupador inclui em seu pacote, dada a mempool atual M e a taxa base r.

Regra de pagamento por pacote: Dado o conjunto de operações selecionadas B, uma regra de pagamento atribui a cada usuário incluído uma taxa:

Função de utilidade do usuário:

Em princípio, poderíamos permitir a existência de uma regra de queima qt(B) expressando o fato de que o agrupador pode não receber a totalidade de todos os pagamentos de usuários incluídos. No entanto, não o consideramos nesta nota.

Função de utilitário de agrupamento (miópico):

Um TFM de nível de pacote (x, p) é compatível com incentivo para agrupadores miope (MBIC) se, para toda a mempool M e taxa básica r, um agrupador míope maximiza sua utilidade seguindo a sugestão da regra de alocação x (ou seja, definindo B = x(M, r)).

Formando múltiplos pacotes

Na seção anterior, consideramos apenas a possibilidade de o aglutinador emitir um único pacote. No entanto, podemos estar interessados na possibilidade de o aglutinador fazer mais de um pacote com as operações disponíveis na mempool. Dado o mempool M, deixe P(M) representar o conjunto de partições da mempool, atribuindo cada operação a um único pacote (podemos supor que, para cada partição, há um conjunto indexado 0 que contém todas as operações não atribuídas a um pacote para inclusão). A regra de alocação então retorna o índice do conjunto na partição ao qual a operação é atribuída.

Podemos escrever o conjunto de pacotes produzidos pela partição x(M,β) como B(x(M,r)). Intuitivamente, esses pacotes são compostos pelas operações que não pertencem ao conjunto indexado 0. Dado um conjunto de pacotes B, a regra de pagamento é então:

A função de utilidade do usuário torna-se:

e a função auxiliar do empacotador se torna:

O jogo do aglutinador

A inclusão de transações em blocos deve remunerar uma quantidade μ aos produtores de blocos, que se presume ser linear no tamanho da transação em, por exemplo, Gate.[Roughgarden, 2021] 3. Esta quantidade denota o custo de oportunidade para o produtor de bloco adicionar uma transação extra ao seu bloco, por exemplo, aumentando o atraso de fofoca e, assim, aumentando suas chances de o bloco ser reorganizado. No Proof-of-Stake, embora o cronograma do protocolo permita tempo suficiente para propaGate um bloco completo,jogos de tempoinduziram dinâmicas de propagação de "último segundo" que mais uma vez tornaram este parâmetro μ relevante.

Em todo caso, podemos observar que o problema de compartilhamento de custos no nível de bloco e no nível de pacote são muito diferentes. No nível de bloco, uma transação não precisa saber o que mais está acontecendo dentro do bloco para elaborar sua oferta de inclusão de acordo com o EIP-1559 (pode querer saber o que está acontecendo em relação ao MEV [Bahrani et al., 2024] 9, mas consideraremos isso como uma questão separada por enquanto). No nível do pacote, os custos gerais do pacote já não são lineares no número de transações, mas um custo fixo pode ser amortizado por muitas transações. Além disso, se o custo de agregação das operações do usuário for não linear no número de transações (por exemplo, algumas provas são efetivamente sub-lineares no tamanho a ser provado), oferecendo a possibilidade de amortizar o custo total entre muitos usuários.

Isso leva ao seguinte jogo: O agrupador deseja que os usuários coloquem seus lances como se estivessem licitando para o pior caso, onde o usuário está sozinho no pacote e deve compensar sozinho o gás total de sobrecarga F. Na prática, o usuário enfrentaria o problema de definir três parâmetros relevantes em sua operação:

• op.maxPriorityFeePerGas e op.maxFeePerGas podem ser definidos de acordo com as heurísticas que um usuário usaria sob EIP-1559, ou seja, dada alguma quantidade estimada de gás que sua operação planeja consumir, o usuário definiria esses atributos para calibrar quanto está disposto a pagar no pior caso (maxFee) e quanto está disposto a completar para pagar ao eventual produtor de blocos (maxPriority). Mas como o usuário deve estimar o gás?
• op.preVerificationGas é um atributo da UserOperation que deve ser definido para indicar a quantidade de "gás extra" que a operação do usuário planeja consumir. Em nosso modelo, deixamos
• F denota esse “overhead de gás fixo”. Se n usuários fossem incluídos no pacote, cada usuário deveria definir preVerificationGas = F / n. No entanto, se o usuário preparar sua operação com um cenário de pior caso em mente, eles definiriam preVerificationGas = F.

preVerificationGas é então o principal vetor por meio do qual os usuários mediam seu lance e tentam contabilizar a amortização dos custos pelo aglutinador. Suponha que n usuários venham ao mercado com suas operações, e todos são convencidos pelo aglutinador a licitar no pior caso de estarem sozinhos no pacote. Também vamos supor que os usuários estejam definindo seu maxPriorityFeePerGas como zero para o bem deste exemplo. Então esses n usuários estão todos definindo preVerificationGas = F, e o aglutinador é capaz de produzir um pacote remunerando-os com:

enquanto eles devem incorrer em um custo:

quando eles publicarem o pacote agrupando todas as n operações juntas em um bloco. Isso gera um lucro π para o agrupador = (n-1) × F × r.

Essa situação pode ser representada por um jogo de duas etapas, onde os usuários primeiro produzem suas operações de usuário e o agrupador decide posteriormente agrupá-los. Supomos que os usuários não possuam informações sobre a quantidade atual de usuários pendentes e, portanto, não são capazes de estimar a verdadeira capacidade do agrupador de amortizar seus custos fixos.

Na primeira fase, os usuários enviam suas operações, que se comprometem com seus atributos, como preVerificationGas. Na segunda fase, o aglutinador, ao receber todas as transações do usuário, decide produzir um pacote ou conjunto de pacotes. Curiosamente, mesmo que os usuários saibam quantos outros usuários vão participar da primeira fase, ou seja, mesmo que n seja um conhecimento comum entre todos os usuários, o aglutinador pode ser capaz de forçar os usuários a definir o preVerificationGas do pior caso = F, ameaçando participar

, ou seja, ameaçando manter cada usuário em seu próprio pacote separado e cobrando-lhes a quantidade máxima de gás F.

Note que essa ameaça pode não ser credível, já que os usuários esperariam que o empacotador preferisse jogar

, ou seja, produzir um único pacote com todas as operações incluídas lá, realizando π. No entanto, os usuários podem não ter acesso ao valor real de n e, portanto, não podem definir seu pré-Verificação-Gás de forma que force o empacotador a idealmente empacotar todos eles.

Caso ideal: os custos são divididos entre os usuários no pacote. Caso pessimista: os usuários pagam a mais e os custos não são divididos.731×755 77.6 KB

Uma extensão desse modelo pode considerar o caso bayesiano, onde os usuários têm acesso a uma distribuição sobre n, ou seja, eles podem antecipar que alguma variável aleatória n usuários apareçam em um determinado passo de tempo, de acordo com alguma distribuição (por exemplo, chegadas de Poisson), mesmo que não saibam antecipadamente o resultado da variável aleatória. Isso pode levar a resultados ineficientes, como mostra o exemplo a seguir:

Alice espera que outros 9 usuários apareçam além dela e, portanto, define seu preVerificationGas para 1, pois ela sabe que F = 10. O valor de Alice e o valor de todos os outros usuários são compatíveis com eles configurando preVerificationGas = 3, mas ela tenta pagar a menor quantia possível para sua inclusão. Como acontece, apenas 5 usuários aparecem no mercado, que também definiram seu preVerificationGas para 1. O bundler não será compensado por F = 10 unidades de gás, portanto, o bundler não produzirá um pacote e os usuários receberão 0 utilidade. Isso é obviamente subótimo, já que os usuários poderiam ter todos configurado preVerificationGas = 2, por exemplo, e receber 1 utilidade (o máximo preVerificationGas que eles estavam dispostos a configurar menos o preVerificationGas real que eles pagaram para serem incluídos).

Trabalho futuro

Conforme o jogo do agrupador mostra, um problema de alocação enfrenta o usuário que deseja ser incluído pelo agrupador. Na próxima nota, abordaremos diferentes abordagens para recuperar uma 'boa UX' para o usuário a fim de evitar que paguem demais a um agrupador que está melhor informado sobre a demanda por sua capacidade de agrupamento. A próxima exploração exigirá uma compreensão da estrutura de mercado que une usuários, agrupadores e construtores/produtores de blocos.

Aviso legal：

1. Este artigo é reproduzido de [ ethresear], Todos os direitos autorais pertencem ao autor original [DavideRezzoli]. Se houver objeções a esta reimpressão, entre em contato com o Portão Aprenderequipe, e eles cuidarão disso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo menção em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.