Introdução

No nosso anterior postagem 15, introduzimos o modelo ERC-4337. Este modelo delineia a estrutura do mercado de taxas para bundlers e detalha a função de custo relacionada ao custo de publicação em cadeia e ao custo de agregação fora da cadeia de um bundle.

Também introduzimos o conceito de “Jogo de Agrupamento”. Este jogo será o foco principal da segunda parte. Dado um conjunto de transações, um agrupador pode escolher quais transações incluir em seu conjunto. Isso cria uma assimetria de informação entre os agrupadores e o usuário, pois o usuário não sabe quantas transações serão incluídas no conjunto. Isso leva a um jogo de soma zero em que o usuário está em clara desvantagem.

Esta pesquisa tem como objetivo explorar métodos para melhorar a UX, garantindo que os utilizadores não precisem de pagar a mais para serem incluídos no próximo pacote. Em vez disso, os utilizadores devem ser capazes de pagar uma taxa com base na procura real de mercado para a inclusão.

Estado atual do ERC-4337

No mercado de hoje, a mempool P2P não está ativa na mainnet e está a ser testada na testnet Sepolia. As empresas que constroem na ERC-4337 estão atualmente a operar em modo privado, os utilizadores ligam-se via RPC a um bundler privado que trabalhará com um buidler para publicar onchain a sua operação do utilizador.Aplicativo Bundle Bear 3, desenvolvido por Kofi, fornece algumas estatísticas intrigantes sobre o estado atual do ERC-4337.

No Pacotes Semanais % Multi-UsuárioOp 1métrica, observamos a percentagem de agrupadores que criam pacotes que incluem múltiplos userops. Desde o início de 2024 até junho de 2024, esta percentagem não excedeu 6,6%. Estes dados tornam-se ainda mais interessantes quando se considera que muitos agrupadores executam os seus próprios patrocinadores, entidades que patrocinam transações em nome dos utilizadores. Notavelmente, os dois maiores agrupadores que também atuam como patrocinadores, em termos de operações de utilizador publicadas,patrocinado 97% 1das operações do usuário usando seus serviços. O pagador paga por algumas partes da operação do usuário e o restante é pago pelos dapps ou outrosentidade 1.

A pergunta que surge é por que os pagadores, dApps, etc., estão a pagar pelas operações do utilizador. O utilizador irá pagar-lhes de volta no futuro? Não podemos ter a certeza do que irá acontecer, mas o meu palpite pessoal é que atualmente, os dApps estão a cobrir as taxas para aumentar a utilização e a adoção das suas apps. Uma vez que a adoção seja elevada, é provável que os utilizadores tenham de pagar pelas transações. Vale a pena mencionar que, para o utilizador pagar por uma operação do utilizador com o modelo atual, não é a melhor opção, uma vez que uma operação básica ERC-4337 custa ~42.000 gas, enquanto uma transação normal custa ~21.000 gas.

Variações sobre ERC-4337

Visão geral do ERC-4337

O mempool ainda está em fase de testes no Sepolia e não está ativo na mainnet. Sem o mempool, os usuários têm opções limitadas para usar a abstração de conta. Os usuários interagem com um RPC, que pode ser oferecido por um agrupador que agrupa UserOps, ou com um serviço RPC que não agrupa, semelhante a serviços como Alchemy ou Infura, que recebem e propagam transações para outros agrupadores.

Uma vez que o mempool esteja ativo, o fluxo de transação será semelhante ao diagrama abaixo, que é semelhante ao fluxo de transação atual. Um mempool aumenta a resistência à censura para os usuários porque, ao contrário do modelo RPC, reduz as chances de uma transação ser excluída. No entanto, mesmo com um mempool, ainda há o risco de um provedor RPC não encaminhar a transação, mas o modelo de mempool é particularmente benéfico para usuários que preferem executar seus próprios nós, pois isso mitiga esse risco.

Embora os agrupadores tenham o potencial de atuar como construtores, preferimos manter os papéis separados devido ao cenário competitivo. Os agrupadores enfrentariam uma competição significativa dos construtores já existentes e sofisticados, tornando a construção menos atraente e potencialmente menos lucrativa. Como resultado, os agrupadores são mais incentivados a colaborar com os construtores estabelecidos em vez de construir de forma independente e correr o risco de perdas.

Combinar os papéis de agrupador e construtor numa única entidade implica alterações significativas no sistema atual. Os agrupadores teriam de competir com os existentes construtores sofisticados, ou alternativamente, os construtores atuais precisarão integrar horizontalmente e assumir também o papel de agrupador. O último cenário, embora mais plausível, levanta preocupações sobre a concentração de mercado e o potencial impacto negativo na resistência à censura.

Empacotadores e construtores como duas entidades diferentes

Com os usuários conectando diretamente a um RPC, tudo é executado em um ambiente mais privado, o que não ajuda na competição de mercado. Em um futuro próximo, a mempool estará na mainnet aumentando a concorrência.

Usar uma mempool, na qual as operações do utilizador são públicas para diferentes bundlers aumenta a concorrência, no caso de abstração de conta não nativa, é necessária uma separação entre bundler e construtor, no caso de abstração de conta nativa, a separação pode não ser necessária, uma vez que o construtor pode interpretar as operações do utilizador como transações normais.

Isso poderia levar ao seguinte resultado: em um ambiente competitivo, os empacotadores baixarão seus preços para serem selecionados pelos usuários, que, por sua vez, buscarão o menor preço para a inclusão de sua operação de usuário em um pacote. Esta concorrência criará um sistema em que o empacotador que oferece o melhor preço será selecionado com mais frequência do que o empacotador que está apenas tentando maximizar seu lucro criando pacotes menores. Separar os papéis do empacotador e do construtor também pode aumentar a resistência à censura. Um bundler pode criar um pacote de operações de usuário aggreGated e enviá-lo para diferentes construtores. Se o pacote incluir operações que podem ser censuradas, um construtor que não censura pode aceitá-lo e prosseguir com a construção. No entanto, vale a pena notar que, do ponto de vista do usuário, essa configuração pode aumentar os custos, já que a introdução de um bundler adiciona uma parte adicional, levando a despesas mais altas.

RIP-7560

A abstração de conta nativa não é um conceito novo; tem estado em pesquisa há anos. Embora o ERC-4337 esteja ganhando tração, a sua implementação fora do protocolo oferece vantagens distintas juntamente com compromissos. Notavelmente, as EOAs existentes não podem fazer a transição de forma transparente para SCWs, e vários tipos de listas resistentes à censura são mais difíceis de utilizar. Como mencionado anteriormente, o custo de operação do gás de um userOp aumenta significativamente em comparação com uma transação normal.RIP-7560 2não resolverá intrinsecamente o problema em curso relacionado aos custos off-chain, mas reduzirá substancialmente as despesas de transação. A partir dos ~42000 gas iniciais, é possível reduzir o custo em~20000 gas.

Abstração de Conta Layer2s

A abstração de contas pode ser utilizada em soluções de Camada 2 (L2). Alguns L2s já a implementam nativamente, enquanto outros seguem a abordagem L1 e estão aguardando uma nova proposta semelhante ao RIP-7560. No L2, o L1 é utilizado para a disponibilidade de dados para herdar segurança, enquanto a maior parte da computação ocorre off-chain no L2, proporcionando transações mais baratas e escalabilidade.

Em cenários onde o cálculo na L2 é significativamente mais barato do que o custo de calldata para disponibilidade de dados (DA) na mainchain, o uso da agregação de assinaturas revela-se altamente benéfico. Por exemplo, o emparelhamento para BLS na mainnet é facilitado pelo 0x08 1pré-compilar a partir do EVM, o que custa aproximadamente ~45000k gás. Consequentemente, usar BLS na L1 é mais caro do que transações tradicionais.

As técnicas de compressão em L2s já estão a ser utilizadas, como a compressão de 0 bytes, que reduz o custo de cerca de 188 bytes para cerca de 154 bytes para uma transferência ERC20. Com a agregação de assinaturas, a eficiência de compressão pode ser ainda mais aprimorada usando uma única assinatura, reduzindo o tamanho para cerca de 128 bytes.

Em Layer 2s, a agregação de assinaturas é uma inovação crucial que melhora tanto a eficiência das transações como a rentabilidade. Ao combinar múltiplas assinaturas numa única, a carga global de dados é significativamente reduzida, o que diminui os custos associados à disponibilidade de dados na Camada 1. Este avanço não só melhora a escalabilidade, como também reduz os custos das transações para os utilizadores, tornando o sistema mais económico e eficiente.

Economia de agregação de assinaturas em camadas 2

Ao utilizar um serviço L2, o utilizador incorre em vários custos, incluindo uma taxa para o operador L2, um custo baseado na congestão da rede e o custo da disponibilidade de dados no L1.

De uma pesquisa anterior sobre ”Compreender a economia de rollup a partir dos primeiros princípiosPodemos esboçar os custos que um utilizador enfrenta ao usar serviços L2 da seguinte forma: "

Quando um usuário interage com uma camada 2, ele tem alguns custos que podemos definir da seguinte forma:

• Taxa do usuário = taxa de publicação de dados L1 + taxa do operador L2 + taxa de congestão L2
• Custo do operador = Custo do operador L2 + Custo de publicação de dados L1
• Receita do operador = Taxas do usuário + MEV
• Lucro do operador = receita do operador - custo do operador = taxa de congestão L2 + MEV

No caso de não ser uma abstração de conta nativa, uma entidade adicional, o bundler, pode introduzir uma taxa para criar pacotes de operações do usuário.

Considerando o agrupador, os custos e lucros são estendidos da seguinte forma:

• Taxa do utilizador = taxa de publicação de dados L1 + taxa do operador L2 + taxa de congestão L2 + taxa do consolidador
• Custo do Agrupador = Cotação (Taxa de publicação de dados L1 + Taxa do operador L2 + Taxa de congestionamento L2)
• Receita do pacote = Taxa do usuário
• Lucro do agrupador = Receita do agrupador - Custo do agrupador = Diferença entre os custos de L1 e L2 e os preços cotados do agrupador + Taxa do agrupador
• Custo do operador = taxa de publicação de dados L1 + taxa do operador L2
• Lucro do operador = Receita do operador - Custo do operador = Taxa de congestionamento L2 + MEV

O agrupador ganha a sua taxa do utilizador pelos seus serviços, enquanto o restante do pagamento do utilizador cobre os custos do operador L2. Se o utilizador não estiver ciente do tamanho do pacote, estimar o custo real de envio de operações do utilizador torna-se desafiante, podendo levar o agrupador a cobrar taxas mais altas do que as necessárias para cobrir o custo do operador.

Alinhamento de incentivos em L2

A interação entre o agrupador e o L2 ajuda a resolver esse problema, pois os L2s são incentivados a manter os custos do usuário baixos devido à concorrência. Cobrar demais dos usuários pode levá-los a mudar para outros L2s que oferecem preços mais justos.

Vamos redefinir nosso modelo introduzindo o operador. O usuário faz lances ao agrupador para inclusão no próximo bloco L2 ao licitar um valor V. O usuário tem como objetivo minimizar a taxa de publicação de dados, enquanto o agrupador procura maximizar sua taxa ou obter um excedente dos custos de interação L2 e taxas do usuário.

Os custos associados à criação de um pacote e à publicação na cadeia podem ser divididos em duas partes:

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

Função de custo aggreGated: O bundler tem uma função de custo para agregar n transações em um único pacote B com taxa base de r:

com S′F, que contém a publicação e verificação da assinatura agregada única na cadeia.

Se o usuário puder obter uma estimativa confiável para n, eles podem calcular seu custo usando a função estimateGas, disponível na maioria das soluções L2. Ter uma boa estimativa pode fazer com que o usuário faça lances de acordo, sem precisar superestimar seu lance para inclusão. Essa função determina o custo necessário para garantir a inclusão. Ter uma boa estimativa para n e a função estimateGas pode evitar que o usuário pague por um preVerificationGas mais alto. Na próxima seção, exploraremos vários mecanismos para garantir uma estimativa confiável de n.

As Layer2s operam um oracle

O papel do oráculo é monitorizar a mempool e estimar o número de transações presentes. O processo funciona da seguinte forma: a Camada 2 implementa um oráculo para verificar a mempool e depois informa o utilizador sobre o número de transações na mempool. Isto permite ao utilizador estimar o seu lance para inclusão num pacote. A Camada 2 pode solicitar ao bundler para incluir pelo menos um número especificado de transações (n) num pacote, caso contrário o pacote será rejeitado. Uma vez que o bundler reúne transações suficientes para formar um pacote, envia o pacote para a Camada 2, que o encaminha para a mainnet como calldata para disponibilidade de dados.

Proposta do observador691×642 47,4 KB

Layer2s com sequenciador compartilhado

Uma abordagem interessante é ter várias redes de Camada 2 (L2) a correr um sequenciador partilhado. Esta configuração pode fornecer uma estimativa mais precisa da mempool, uma vez que o sequenciador chega a um acordo através do consenso facilitado pelo sequenciador partilhado.

Nesta configuração, diferentes redes L2 operam de forma independente, mas compartilham um sequenciador comum. Em intervalos regulares, essas redes verificam o número de operações do usuário (userops) na mempool compartilhada. O sequenciador compartilhado ajuda a sincronizar e agregar dados dessas redes. Uma vez que elas chegam a um acordo, as informações são comunicadas ao usuário, permitindo que eles façam lances com base no número de userops presentes.

Esta abordagem oferece várias vantagens. Em primeiro lugar, fornece um método descentralizado para determinar o número de userops na mempool, aumentando a resistência à colusão. Em segundo lugar, elimina o único ponto de falha que poderia ocorrer se apenas um sistema estivesse gerenciando a comunicação entre o usuário e a mempool. Em terceiro lugar, o sequenciador compartilhado garante consistência e reduz discrepâncias entre as diferentes soluções L2.

Ao aproveitar o sequenciador compartilhado, este método garante um sistema robusto e confiável para estimar e comunicar o estado do mempool aos usuários, melhorando assim a eficiência e segurança geral do processo.

Shared Sequencer764×785 66.3 KB

Nas duas abordagens explicadas ao usar um oráculo, há um vetor de ataque potencial onde um adversário poderia gerar múltiplas operações de usuário na mempool, sabendo que elas irão reverter se agregadas juntas. Como resultado, o oráculo vê que há

n

transações e exige um grande pacote, mas o agrupador não pode criar o pacote. Este problema pode parar a rede por muitos blocos.

Layer2s operam o seu próprio bundler

Nesta proposta, a própria Camada 2 assume o papel do agregador, enquanto outra entidade manipula a agregação de assinaturas (isto poderia ser serviços de agregação atuais). O processo funciona da seguinte forma: a Camada 2 opera o seu próprio agregador, e os utilizadores enviam as suas operações (userops) para o mempool. A Camada 2 seleciona algumas destas userops do mempool e envia-as “brutas” para o agregador, compensando o agregador pela agregação das assinaturas. Uma vez que o agregador produz o pacote, envia-o para o agregador, que o encaminha para a mainnet como calldata para disponibilidade de dados.

A ideia principal é que a Camada 2 lida com a coleta de userops e, em seguida, terceiriza a agregação para outra entidade. A Camada 2 paga pela agregação e cobra do usuário uma taxa pelo serviço.

Existem duas opções diferentes:

1. Modelo de Taxa Fixa: O agrupador (Sequenciador) seleciona algumas transações e cobra do usuário uma taxa fixa. Essa taxa fixa é calculada de forma semelhante às transações atuais da Camada 2, prevendo o custo futuro da publicação de dados da L1. Alternativamente, a Camada 2 pode cobrar do usuário uma taxa fixa com base no custo do agrupamento n
2. aggreGated userops, a camada 2 ainda tem que prever quantas transações estarão presentes no pacote que ele irá construir para cotar corretamente o usuário, isso pode ser feito da mesma forma como é agora onde o L2 cobra o preço mais competitivo para o usuário. É do melhor interesse do L2 manter os preços o mais competitivos possível para o usuário.
   
3. Taxa fixa 671×702 22,1 KB
4. Pedidos de Reembolso: Se a Camada 2 quiser melhorar a sua credibilidade, poderia permitir reembolsos automáticos. Isso envolveria um mecanismo que verifica quantas userops são publicadas num único bloco e se as transações poderiam ter sido agregadas. Se uma userop que poderia ter sido agregada não o foi e nenhum reembolso automático foi emitido, o utilizador pode solicitar um reembolso. Neste cenário, a Camada 2 poderia apostar alguns ativos e, se o reembolso não for fornecido, o utilizador poderia impor o reembolso, garantindo a justiça e a responsabilidade.
   
5. Pedido de reembolso 671×702 22,8 KB

Conclusão

Nesses dois posts diferentes, destacamos as dificuldades que os usuários enfrentam ao fazer lances para serem incluídos no próximo pacote. Na primeira parte, apresentamos o modelo ERC-4337, explicando os custos que um empacotador incorre ao postar um pacote na cadeia e os custos associados fora da cadeia. Também destacamos os mercados de taxas para empacotadores e começamos a discutir o problema de formatar o empacotador. Os usuários enfrentam dificuldades ao fazer lances devido à falta de conhecimento sobre o número de transações presentes no mempool no momento do empacotamento.

Na segunda parte, explicamos ERC-4337 e RIP-7560. Em seguida, discutimos por que a agregação de assinatura é mais provável de ocorrer em soluções de Camada 2 do que diretamente na Camada 1. Demonstramos como as soluções de Camada 2 podem abordar o conhecimento assimétrico que os usuários experimentam de diferentes maneiras. A primeira é usar oráculos para sinalizar ao usuário quantas transações estão presentes no mempool, com essa abordagem os usuários sabem quanto devem dar lances e podem forçar o bundler a fazer pacotes maiores. A terceira abordagem, que é a mais simples, é que o L2 atua como um empacotador e terceiriza a agregação para terceiros e permite que os usuários paguem uma taxa por isso.

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir de [ethresear], Encaminhe o Título Original 'Mercados de taxas embutidas e ERC-4337 (parte 2)', Todos os direitos autorais pertencem ao autor original [ DavideRezzoli & Barnabé Monnot]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.

2. Aviso de Responsabilidade: As opiniões expressas 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 equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.