Introdução

Em nosso anterior post 15, introduzimos o modelo ERC-4337. Este modelo descreve a estrutura do mercado de taxas para os bundlers e detalha a função de custo relacionada ao custo de publicação on-chain e aos custos off-chain (custos de agregação) de um bundle.

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

Esta pesquisa tem como objetivo explorar métodos para melhorar a experiência do usuário, garantindo que os usuários não precisem pagar a mais para serem incluídos no próximo pacote. Em vez disso, os usuários devem ser capazes de pagar uma taxa com base na demanda real do mercado para inclusão.

Estado atual do ERC-4337

No mercado atual, a mempool P2P não está ativa na mainnet e está sendo testada na testnet Sepolia. As empresas que estão construindo na ERC-4337 estão operando atualmente em modo privado, os usuários se conectam via RPC a um agrupador privado que então trabalhará com um construtor para publicar sua operação de usuário na cadeia.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 1No métrico, observamos a porcentagem de agrupadores que criam pacotes que incluem várias operações de usuário. Desde o início de 2024 até junho de 2024, essa porcentagem não ultrapassou 6,6%. Esses dados se tornam ainda mais interessantes ao considerar que muitos agrupadores executam seus próprios mestres de pagamento, entidades que patrocinam transações em nome dos usuários. Notavelmente, os dois maiores agrupadores que também atuam como mestres de pagamento, em termos de operações de usuário 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 questão que surge é por que os pagadores, dApps, etc., estão pagando pelas operações do usuário. O usuário irá pagá-los de volta no futuro? Não podemos ter certeza do que acontecerá, mas meu palpite pessoal é que atualmente, os dApps estão cobrindo as taxas para aumentar o uso e a adoção de seus aplicativos. Uma vez que a adoção seja alta, os usuários provavelmente terão que pagar pelas transações. Vale ressaltar que para o usuário pagar por uma operação de usuário com o modelo atual não é a melhor opção, já que uma operação básica do ERC-4337 custa ~42.000 gas, enquanto uma transação normal custa ~21.000 gas.

Variações em ERC-4337

Visão geral do ERC-4337

A mempool ainda está em fase de teste em Sepolia e não está ativa 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 a mempool está ativa, o fluxo de transações se assemelhará ao diagrama abaixo, que é semelhante ao fluxo de transações atual. A mempool melhora 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 uma mempool, ainda há o risco de um provedor RPC não encaminhar a transação, mas o modelo mempool é especialmente benéfico para usuários que preferem executar seus próprios nós, pois 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 concorrência significativa dos construtores existentes e sofisticados, tornando a construção menos atraente e potencialmente menos lucrativa. Como resultado, os agrupadores são mais incentivados a colaborar com construtores estabelecidos, em vez de construir de forma independente e correr o risco de sofrer perdas.

Combinar os papéis de agrupador e construtor em uma única entidade implica em mudanças significativas no sistema atual. Os agrupadores precisariam competir com os existentes construtores sofisticados, ou alternativamente, os construtores atuais precisarão integrar horizontalmente e assumir também o papel de agrupador. Este ú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.

Agrupadores e construtores como duas entidades diferentes

Com os usuários se conectando diretamente a um RPC, tudo funciona 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 competição.

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

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

RIP-7560

A abstração de conta nativa não é um conceito novo; vem sendo pesquisado há anos. Embora o ERC-4337 esteja ganhando tração, sua implementação fora do protocolo oferece vantagens distintas, além de compensações. Notavelmente, as ACs existentes não podem fazer a transição perfeita para os ACs inteligentes, e vários tipos de listas resistentes à censura são mais difíceis de utilizar. Como mencionado anteriormente, o custo de overhead de gás de uma operação do usuário aumenta significativamente em comparação com uma transação normal.RIP-7560 2não resolverá inherentemente a questão em curso relativa aos custos off-chain, mas reduzirá substancialmente as despesas de transação. A partir do gás inicial de ~42000, é possível reduzir o custo em~20000 gás.

Abstração de Conta Layer2s

A abstração de conta 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 disponibilidade de dados para herdar segurança, enquanto a maior parte da computação ocorre fora da cadeia no L2, proporcionando transações mais baratas e escalabilidade.

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

Técnicas de compressão em L2 já estão sendo utilizadas, como a compressão de 0 bytes, que reduz o custo de ~188 bytes para ~154 bytes em uma transferência ERC20. Com a agregação de assinaturas, a eficiência de compressão pode ser ainda maior, usando uma única assinatura e reduzindo o tamanho para ~128 bytes.

Em Layer 2s, a agregação de assinaturas é uma inovação crucial que aprimora tanto a eficiência de transações quanto a rentabilidade. Ao combinar múltiplas assinaturas em uma única, a carga de dados geral é significativamente reduzida, o que diminui os custos associados à disponibilidade de dados na Camada 1. Esse avanço não apenas melhora a escalabilidade, mas também reduz os custos de transação para os usuários, tornando o sistema mais econômico e eficiente.

Economia de Agregação de Assinaturas em Camadas2s

Ao usar um serviço L2, o usuário 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 na L1.

De uma pesquisa anterior sobre ”Compreendendo a economia da rollup a partir dos primeiros princípios”, podemos resumir os custos que um usuário 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 congestionamento 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 congestionamento L2 + MEV

No caso de abstração de contas não nativas, uma entidade adicional, o agrupador, pode introduzir uma taxa para criar pacotes de operações do usuário.

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

• Taxa do usuário = taxa de publicação de dados L1 + taxa de operador L2 + taxa de congestionamento L2 + Taxa do agregador
• Custo do Agregador = Cotação (taxa de publicação de dados L1 + taxa de operador L2 + taxa de congestão 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 sua taxa do usuário por seus serviços, enquanto o restante do pagamento do usuário cobre os custos do operador L2. Se o usuário não estiver ciente do tamanho do pacote, estimar o custo real do envio de userops se torna um desafio, 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 à competição. Cobrar demais dos usuários pode fazê-los mudar para outros L2s que oferecem preços mais justos.

Vamos redefinir nosso modelo introduzindo o operador. O usuário faz uma oferta ao bundler para inclusão no próximo bloco L2, fazendo uma oferta de valor V. O usuário tem como objetivo minimizar a taxa de publicação de dados, enquanto o bundler busca 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 emitiu o pacote B quando a taxa base é r, gasta um custo:

Função de custo agregada: O agrupador possui 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. Esta 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 um preVerificationGas mais alto. Na próxima seção, exploraremos vários mecanismos para garantir uma estimativa confiável de n.

Layer2s operam um oráculo

O papel do oráculo é monitorar o mempool e estimar o número de transações presentes. O processo funciona da seguinte forma: a Camada 2 implanta um oráculo para verificar o mempool e depois informa o usuário sobre o número de transações no mempool. Isso permite que o usuário estime sua oferta para inclusão em um pacote. A Camada 2 pode solicitar ao aglutinador que inclua pelo menos um número especificado de transações (n) em um pacote, caso contrário o pacote será rejeitado. Depois que o aglutinador reúne transações suficientes para formar um pacote, ele envia o pacote para a Camada 2, que então o encaminha para a mainnet como calldata para disponibilidade de dados.

Proposta de observador 691 × 642 47,4 KB

Layer2s com sequenciador compartilhado

Uma abordagem interessante é ter várias redes de Camada 2 (L2) executando um sequenciador compartilhado. Essa configuração pode fornecer uma estimativa mais precisa do mempool, já que o sequenciador chega a um acordo por meio de consenso facilitado pelo sequenciador compartilhado.

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 de usuário (userops) na mempool compartilhada. O sequenciador compartilhado ajuda a sincronizar e aggreGate dados dessas redes. Uma vez que chegam a um acordo, as informações são comunicadas ao usuário, permitindo-lhes licitar 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 ponto único 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 a segurança geral do processo.

Sequenciador Compartilhado764×785 66.3 KB

Nas duas abordagens explicadas usando um oráculo, há um vetor de ataque potencial onde um adversário poderia gerar várias operações de usuário no mempool, sabendo que elas serão revertidas se agrupadas. Como resultado, o oráculo vê que existem

n

transações e requer um pacote grande, mas o empacotador não pode criar o pacote. Esse problema pode paralisar a rede por muitos blocos.

Layer2s operam seu próprio bundler

Nesta proposta, a própria Camada 2 assume o papel do empacotador, enquanto outra entidade lida com a agregação de assinaturas (isso pode ser os serviços atuais do empacotador). O processo funciona da seguinte forma: a Camada 2 opera seu próprio empacotador e os usuários enviam suas operações (userops) para o mempool. A Camada 2 seleciona alguns desses userops do mempool e os envia "brutos" para o agregador, compensando o agregador por agregar as assinaturas. Depois que o agregador produz o pacote, ele o envia para o empacotador, 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 depois 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 na Camada 1. Alternativamente, a Camada 2 pode cobrar do usuário uma taxa fixa com base no custo do agrupamento n
2. usuários agregados, 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 que é agora onde a L2 cobra o melhor preço competitivo para o usuário, sendo do melhor interesse da Camada 2 manter os preços o mais competitivos possível para o usuário.
   
3. Taxa fixa 671×702 22.1 KB
4. Solicitação de reembolsos: Se a Camada 2 deseja aumentar sua credibilidade, ela poderia habilitar reembolsos automáticos. Isso envolveria um mecanismo que verifica quantas operações de usuário são publicadas em um único bloco e se as transações poderiam ter sido agregadas. Se uma operação de usuário que poderia ter sido agregada não foi, e nenhum reembolso automático foi emitido, o usuário pode solicitar um reembolso. Nesse cenário, a Camada 2 poderia apostar alguns ativos, e se o reembolso não for fornecido, o usuário poderia fazer valer o reembolso, garantindo justiça e responsabilidade.
   
5. Solicitar Reembolso671×702 22.8 KB

Conclusão

Nesses dois posts diferentes, destacamos as dificuldades que os usuários enfrentam ao tentar ser incluídos no próximo conjunto. Na primeira parte, apresentamos o modelo ERC-4337, explicando os custos que um agrupador incorre ao postar um conjunto on-chain e os custos off-chain associados. Também destacamos os mercados de taxas para os agrupadores e começamos a discutir o problema de formatação do agrupador. Os usuários enfrentam dificuldades com lances devido à falta de conhecimento sobre o número de transações presentes na mempool no momento do agrupamento.

Na segunda parte, explicamos o ERC-4337 e o RIP-7560. Em seguida, discutimos por que a agregação de assinaturas é 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 lidar com 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 na mempool, com essa abordagem, o usuário sabe quanto deve oferecer e pode forçar o bundler a criar feixes maiores. A terceira abordagem, que é a mais simples, é que a L2 atua como um bundler e terceiriza a agregação para uma terceira parte, permitindo que os usuários paguem uma taxa por isso.

Aviso Legal:

1. Este artigo é reproduzido a partir de [ethresear], Encaminhe o Título Original 'Mercados de Taxas Incorporadas e ERC-4337 (parte 2)', Todos os direitos autorais pertencem ao autor original [DavideRezzoli & Barnabé Monnot]. Se houver objeções a este reenvio, entre em contato com o Gate Aprendaequipe, e eles vão lidar com isso 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 equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.