Os mecanismos de taxa de transação tornaram-se os modelos de trabalho para entender a intermediação dos produtores de blocos entre os usuários que desejam transacionar e a 'cadeia' (ou '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 a capacidade de usar o recurso escasso da execução na cadeia 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 de bloco para bloco, chamado 'taxa base'. A taxa base é um preço, expresso por unidades de gás, que uma transação de usuário deve pagar para ser incluída e executada. O usuário pode fornecer as chamadas 'taxas de prioridade' além da taxa base, para incentivar ainda mais os produtores de blocos em tempos de congestionamento.

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

Na nossa configuração, os utilizadores desejam aceder à cadeia, mas não expressam a sua procura através de transações legíveis pelo protocolo. Em vez disso, os utilizadores produzem “operações”, a serem agrupadas por entidades conhecidas como “agrupadores”, que então originam uma transação legível pelo protocolo, agrupando as operações em direção à execução. Assim, para o mecanismo de taxas EIP-1559, os agrupadores são os utilizadores da cadeia, contudo, os utilizadores reais devem primeiro obter inclusão no conjunto de um agrupador antes de poderem obter inclusão na cadeia. Em outras palavras, podemos ver esta configuração como parte da questão maior de co-criação de blocos, que surge com construtores/pesquisadores (parciais) e listas de inclusão.

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

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

Modelo

Agrupamento em ERC-4337

Um usuário que deseja realizar alguma atividade on-chain através de bundlers emite uma Operação de Usuário (UserOp, ou operação). Este UserOp é emitido a partir da carteira do utilizador, por exemplo, depois de interagir com um DApp. Uma vez que o UserOp é transmitido, algum bundler que recebe a operação pode decidir incluí-lo em um pacote. Um pacote é uma metatransação de "conta de propriedade externa" (EOA), que grava os dados do UserOps incluído em seu campo bundle.calldata. O bundler emite o bundle para inclusão em um bloco por um produtor de bloco (discutimos a relação entre bundler e produtor de bloco 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, os passos de execução do pacote são os seguintes:

• Pré-verificação: A transação EOA do agrupador consumirá 21.000 de gás, e a chamada ao contrato de ponto de entrada configurará variáveis chave para acompanhar a execução das operações no loop de operações.
• Operação loop 3: Para cada operação incluída no pacote, ocorrem os seguintes dois passos:
  • Etapa de verificação: UserOps executa 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 executar operações mais complexas para "conceder" o direito de o UserOp prosseguir com sua execução. A etapa de verificação é medida por op.verificationGasLimit.
  • Passo de execução: O núcleo do UserOp, o passo de execução realiza a operação descrita em op.callData. Este passo também é medido, utilizando op.callGasLimit.

Como é evidente pela decomposição anterior, o passo de pré-verificação é executado uma vez, oferecendo a possibilidade de amortizar os custos da pré-verificação entre todos os utilizadores 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 inclui) são cobrados ao agrupador, que deve garantir que as operações do utilizador a compensem suficientemente pelos custos incorridos. Tornamos estas afirmações precisas na secção seguinte.

Modelo de mercado de taxas para pacotes

Tentamos manter a coerência com os modelos clássicos dos 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, o mesmo gás usado para as etapas de verificação e execução) e, portanto, expressamos todas as quantidades como preços por unidade de gás.

Os utilizadores expressam o seu desejo de serem incluídos ao emitirem uma licitação bt juntamente com a sua operação. Por agora, não assumimos uma gramática específica para o utilizador expressar a sua licitação para inclusão, por exemplo, a capacidade de expressar uma taxa máxima e uma taxa prioritária juntamente com a sua operação, como fariam com o EIP-1559. As operações do utilizador são recolhidas numa mempool M, representando o estado pendente destas operações até à 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 contiver n operações, o agrupador deverá 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 fornecidas pelo conjunto B.

Funções de custo do agrupador

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

Função de custo on-chain: Um empacotador que emite o pacote B quando a taxa base é r gasta um custo:

O problema do aglomerador 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 assim aumenta o risco de re-org). O mercado de taxas ao nível do 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 ao nível do agrupador requererá pelo menos compensar o agrupador por custos exógenos.

Con-chain(B,r) que eles incorrem do mercado de taxas mais elevadas em que estão inseridos.

O ERC-4337 oferece a possibilidade de amortizar custos para além da partilha dos custos do gás pré-verificação. Se todas as operações utilizarem o mesmo esquema de assinatura para a sua etapa de verificação, as assinaturas dessas operações podem ser agregado 2pelo agrupador, de modo que, em vez de verificar n assinaturas na cadeia, uma única assinatura pode ser verificada. Nesse caso, a função de custo do agrupador precisará levar em conta os custos fora da cadeia que o agrupador incorre ao realizar a agregação. A seguir, assumimos 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 levamos em consideração o consumo reduzido de gás de cada operação, devido a economias da agregação. Quando agregadas, as operações não precisam publicar sua assinatura, mas exigem uma operação adicional de emparelhamento. Em cadeias onde o custo dos dados de chamada é caro, mas as operações de emparelhamento/computação são baratas, a agregação assim fornece economias por operação. Nesse caso, denotamos por S' < S o tamanho reduzido de uma transação. Também precisamos levar em consideração 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 em cadeia.

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

Nesta nota, não iremos mais longe, mas também é possível considerar os custos de publicação de dados que um aglomerador pode precisar gastar quando seu pacote é liquidado em um rollup. Sugerimos duas maneiras de modelar isso e deixamos essa pergunta para trabalhos futuros:

• Ou a própria agrupadora é responsável pela publicação dos dados (por exemplo, como um sequenciador) e, portanto, precisa obter dos usuários a quantidade necessária de fundos para pagar os eventuais custos de publicação dos dados.
• Ou o mercado de taxas ao nível do pacote está incorporado num mercado de taxas ao nível do lote maior, através do qual o rollup expõe aos utilizadores do rollup (incluindo o agrupador) o montante que devem pagar devido à congestão (por exemplo, uma taxa base) e aos eventuais custos de publicação de dados. Neste caso, o rollup é responsável por equilibrar os seus próprios custos futuros com as suas receitas presentes.

Revisitando quantidades de mercado de taxas

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

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

Regra de pagamento ao nível do pacote: Dado o conjunto de operações selecionadas B, uma regra de pagamento atribui a cada utilizador incluído uma taxa:

Função de utilidade do utilizador:

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

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

Um TFM a nível de pacote (x, p) é compatível com incentivos para bundlers miope (MBIC) se, para cada mempool M e taxa base r, um bundler miope maximiza sua utilidade seguindo a sugestão da regra de alocação x (ou seja, definindo B = x(M,r)).

Formando vários pacotes

Na seção anterior, consideramos apenas a possibilidade de o empacotador emitir um único pacote. No entanto, podemos estar interessados na possibilidade de o bundler fazer mais de um pacote das operações disponíveis no mempool. Dado o mempool M, deixe P(M) representar o conjunto de partições do mempool, atribuindo cada operação a um único bundle (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 bundle para inclusão). Em seguida, a regra de alocação retorna o índice do conjunto na partição à 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 utilitária bundler torna-se:

O jogo do bundler

A inclusão de transações nos blocos deve remunerar uma certa quantidade μ aos produtores de blocos, que se assume ser linear no tamanho da transação, por exemplo, [Roughgarden, 2021] 3. Esta quantidade denota o custo de oportunidade para o produtor de blocos 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, mesmo que o cronograma do protocolo permita tempo suficiente para propagar um bloco completo, jogos de tempoinduziram dinâmicas de propagação 'no último segundo' que mais uma vez tornaram este parâmetro μ relevante.

Em qualquer caso, podemos observar que o problema de partilha de custos ao nível do bloco e ao nível do pacote são muito diferentes. Ao nível do bloco, uma transação não precisa de saber o que mais está a acontecer dentro do bloco para elaborar a sua oferta de inclusão de acordo com o EIP-1559 (pode querer saber o que está a acontecer em relação ao MEV).[Bahrani et al., 2024] 9, mas vamos considerar isso uma questão separada por enquanto). Ao nível do pacote, os custos gerais do pacote já não são lineares no número de transações, mas uma despesa geral fixa pode ser amortizada por muitas transações. Além disso, se o custo de agregação das operações do utilizador não for linear no número de transações (por exemplo, algumas provas são efetivamente sublineares na dimensão comprovada), oferecendo a possibilidade de amortizar o custo total em relação a muitos utilizadores.

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

• op.maxPriorityFeePerGas e op.maxFeePerGas podem ser definidos de acordo com a heurística que um usuário usaria sob o EIP-1559, ou seja, dado algum montante estimado de gás que sua operação planeja consumir, o usuário definiria esses atributos para calibrar quanto estão dispostos a pagar no pior caso (maxFee) e quanto estão dispostos a adicionar para pagar ao produtor de bloco eventual (maxPriority). Mas como o usuário deve estimar o gás?
• op.preVerificationGas é um atributo do UserOperation que deve ser definido para indicar a quantidade de "gás extra" que a operação do usuário planeja consumir. No nosso modelo, deixamos
• F denote this “fixed gas overhead”. If n users were included in the bundle, each user ought to set preVerificationGas = F / n. However, should the user prepare their operation with a worst-case scenario in mind, they would set preVerificationGas = F.

preVerificationGas é então o principal vetor através do qual os usuários mediam sua oferta e tentam contabilizar a amortização dos custos pelo agrupador. Suponha que n usuários venham ao mercado com suas operações e todos sejam convencidos pelo agrupador a fazer lances no pior caso de estarem sozinhos no pacote. Também vamos supor que os usuários estejam definindo maxPriorityFeePerGas como zero neste exemplo. Então, esses n usuários estão todos definindo preVerificationGas = F, e o agrupador é capaz de gerar um pacote remunerando-os com:

enquanto eles devem incorrer em um custo:

uma vez que eles publicam o pacote agrupando todas as operações n em um bloco. Isso dá ao empacotador um lucro π = (n−1)×F×r.

Esta situação pode ser representada por um jogo de duas fases, onde os utilizadores produzem primeiro as suas operações de utilizador, e o agregador decide posteriormente agrupá-las. Assumimos que os usuários não possuem informações sobre a quantidade atual de usuários pendentes e, portanto, são incapazes de estimar a verdadeira capacidade do empacotador de amortizar seus custos fixos.

Na primeira fase, os utilizadores enviam as suas operações, que se comprometem com os seus atributos, como preVerificationGas. Na segunda fase, o agrupador, tendo recebido todas as transações dos utilizadores, decide produzir um pacote ou conjunto de pacotes. Curiosamente, mesmo que os utilizadores saibam quantos outros utilizadores irão participar na primeira fase, ou seja, mesmo que n seja conhecido por todos os utilizadores, o agrupador pode forçar os utilizadores a definir preVerificationGas = F no pior caso, 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 gas F.

Note que esta ameaça pode não ser credível, uma vez que os utilizadores esperariam que o agrupador preferisse jogar

, ou seja, produzir um único pacote com todas as operações incluídas lá, realizando π. No entanto, os utilizadores podem não ter acesso ao valor real de n e, assim, não conseguem definir o seu preVerificationGas de forma a obrigar o agrupador a agrupar idealmente todos eles.

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

Uma extensão deste modelo pode considerar o caso Bayesiano, onde os utilizadores têm acesso a uma distribuição ao longo de n, ou seja, podem antecipar a presença de um número n de utilizadores em qualquer momento, de acordo com alguma distribuição (por exemplo, chegadas de Poisson), mesmo que não saibam antecipadamente o resultado da variável aleatória. Isto pode levar a resultados ineficientes, como mostra o exemplo seguinte:

Alice espera que outros 9 utilizadores apareçam, além dela, e por isso define o seu preVerificationGas como 1, pois sabe que F = 10. O valor de Alice e o valor de todos os outros utilizadores é compatível com eles definirem preVerificationGas = 3, mas ela tenta pagar a menor quantia possível para a sua inclusão. Acontece que apenas 5 utilizadores aparecem no mercado, que também definiram o seu preVerificationGas como 1. O agrupador não será compensado por F = 10 unidades de gás, assim o agrupador não produz um conjunto e os utilizadores recebem 0 utilidade. Obviamente, isto é subótimo, pois os utilizadores poderiam todos ter definido preVerificationGas = 2, por exemplo, e receber 1 utilidade (a preVerificationGas máxima que estavam dispostos a definir menos o preVerificationGas real que pagaram para serem incluídos).

Trabalho futuro

Como os jogos de agrupamento mostram, um problema de alocação enfrenta o usuário que deseja ser incluído pelo agrupador. Na próxima nota, abordaremos abordagens diferentes para recuperar uma 'boa experiência do usuário' para evitar que paguem demais a um agrupador que está mais bem 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 juntos.

Aviso Legal:

1. Este artigo é reimpresso de [ethresear], Todos os direitos autorais pertencem ao autor original [DavideRezzoli]. Se houver objeções a essa reimpressão, entre em contato com o Gate Aprenderequipa, e eles tratarão disso prontamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.