Tokens nativos da Camada 2 como pagamento de taxas de transação: Análise técnica

Este artigo técnico examina as vantagens e desvantagens de permitir que os usuários paguem taxas de transação com tokens nativos da Camada 2, analisando tanto os mecanismos técnicos quanto as implicações de mercado.

Pré-requisitos

A compreensão dos mecanismos de operação Rollup e dos mecanismos de Inclusão Forçada é recomendada para uma compreensão completa desta análise.

Introdução

A maioria das redes de Camada 2 emite seus próprios tokens, embora muitos sejam usados principalmente para fins de governança ( como Arbitrum e Optimism). Alguns protocolos L2 implementaram mecanismos de staking para seus tokens nativos, incluindo Mantle e Manta. Esses tokens apostados servem a várias funções, como determinar a autoridade de sequenciamento de transações, o poder de geração de provas de conhecimento zero, ou garantir que os requisitos de publicação de dados sejam atendidos. Para detalhes técnicos, consulte a documentação de StarkNet, zkSync, Mantle e Manta.

Nota técnica: A verificação objetiva da "publicação correta de dados" apresenta desafios significativos, tornando difícil a implementação de mecanismos de punição eficazes. Isso levanta questões sobre a eficácia de designs que dependem de "staking de tokens L2 para funcionalidade de publicação de dados."

Pagamento de Taxa de Token Nativo: Análise Técnica e de Mercado

Vantagens Técnicas

A implementação de tokens nativos da Camada 2 como mecanismos de pagamento de taxas expande significativamente a utilidade dos tokens além das funções básicas de governança. Esta abordagem pode ser aprimorada com a implementação de mecanismos EIP-1559 para queimar uma parte dos tokens coletados como taxas, potencialmente criando pressão deflacionária que contribui para a acumulação de valor dentro do ecossistema.

Limitações Técnicas

Desafio de Denominação de Custo de Dados

O problema fundamental permanece que os Sequenciadores de Rollup devem pagar os custos de disponibilidade de dados na moeda nativa L1 (ETH) ao fazer upload de dados de transação para o Ethereum. Isso cria um risco de taxa de câmbio inerente entre quando o Sequenciador recebe tokens L2 como pagamento e quando eles devem converter esses tokens em ETH para os custos de disponibilidade de dados. Esta exposição ao risco acrescenta complexidade operacional para os operadores de Sequenciadores.

Nota técnica: Este problema vai além dos Rollups baseados em Ethereum. Redes L2 que utilizam camadas de disponibilidade de dados alternativas (como Mantle ou Manta) enfrentam desafios idênticos com o token nativo da respectiva camada de DA.

Impacto na Experiência do Usuário

Modelos de taxa de um único token podem criar uma fricção significativa no processo de integração dos usuários. Quando os usuários só podem pagar as taxas com o token nativo da Camada 2, eles enfrentam um problema de dependência circular: precisam do token para realizar transações, mas adquirir o token muitas vezes requer executar uma transação primeiro.

Por exemplo, os usuários que depositam ETH no Polygon PoS pela primeira vez descobrem que não podem usar esse ETH para pagar taxas de transação. Sem tokens MATIC já disponíveis na sua carteira, não conseguem executar a transação necessária para trocar ETH por MATIC. Isso obriga os usuários a primeiro adquirir MATIC na L1 e, em seguida, transferi-lo para o ambiente L2.

Nota técnica: Embora o Polygon PoS seja tecnicamente uma sidechain em vez de um verdadeiro L2, este exemplo ilustra eficazmente o desafio da experiência do usuário.

Esta fricção multiplica-se por todo o ecossistema - com N diferentes redes de Camada 2 a exigirem N diferentes tokens para operações básicas.

Barreiras de Interoperabilidade Cross-L2

Os requisitos de taxa do token nativo criam barreiras técnicas significativas para a interoperabilidade L2 sem costura. Por exemplo, uma transferência básica entre L2 não pode ser concluída apenas com ETH se o L2 de destino exigir seu token nativo para taxas de transação.

Isso força os usuários a gerenciar múltiplas posses de tokens e navegar por desafios complexos de liquidez. Com N diferentes Camadas 2, a liquidez fica fragmentada entre N-1 pares de tokens, exigindo que os usuários realizem N trocas distintas antes de operar em múltiplos ambientes de Camada 2. Operações cruzadas em Camadas 2 mais complexas, como empréstimos, abertura de posições e liquidações enfrentam fricções acumuladas devido a esses requisitos de tokens de taxa.

A visão da Superchain do Optimism para interoperabilidade ilustra perfeitamente esse desafio - se cada Rollup dentro do ecossistema da Superchain exigisse tokens diferentes para o pagamento de taxas, isso minaria diretamente os objetivos fundamentais de interoperabilidade.

No entanto, essas limitações de experiência e interoperabilidade aplicam-se apenas a modelos de taxa de token nativo exclusivos. Abordagens híbridas que suportam pagamentos de taxas em ETH e em tokens nativos podem mitigar esses problemas, permitindo que os usuários escolham ETH para operações entre cadeias enquanto usam tokens L2 para operações nativas quando desejado. A StarkNet está a liderar esta abordagem híbrida, implementando suporte para pagamentos de taxas tanto em ETH como em STRK.

Implementação Técnica: STRK como Taxa de Transação

A StarkNet anunciou recentemente o suporte para pagamentos de taxas com o token STRK ao lado do ETH. Este modelo de taxa de dupla moeda permite que os usuários escolham seu método de pagamento preferido, enquanto o Sequencer ( chamado "Operador" na terminologia StarkNet ) assume o risco da taxa de câmbio entre ETH e STRK. Isso levanta questões técnicas importantes sobre a determinação de taxas para transações.

Análise Técnica da Autoridade do Sequenciador

Em ambas as redes L1 e L2, as transações normalmente especificam uma taxa máxima que o usuário está disposto a pagar. Em cadeias compatíveis com EIP-1559 (Ethereum, Arbitrum, Optimism), os usuários especificam um valor maxFeePerGas, que multiplicado pelo gasLimit define a taxa máxima da transação. As cadeias não compatíveis com EIP-1559 utilizam modelos de taxa fixa.

Nota técnica: StarkNet, embora ainda não implemente o EIP-1559, requer que os usuários especifiquem um parâmetro maxFee.

Os sequenciadores de transações ( mineradores, validadores ou sequenciadores L2 ) mantêm a autoridade para incluir ou excluir transações específicas. No entanto, uma vez incluídas, as transações podem ser cobradas apenas até a taxa máxima especificada pelo usuário.

Análise de Implementação de Oracle

STRK para conversão de taxas. No entanto, esta abordagem ignora a dinâmica fundamental da autoridade do sequenciador - os sequenciadores podem escolher quais transações incluir com base nos seus próprios incentivos econômicos.

O fator crítico continua a ser a taxa máxima que um utilizador especifica ( em ETH ou STRK), após a qual deve esperar pela inclusão. Um oráculo de taxa de câmbio pública não alteraria fundamentalmente esta relação, uma vez que os sequenciadores mantêm a capacidade de cobrar até à taxa máxima especificada.

Arquitetura de Oracle Off-chain para StarkNet

STRK especificamente para operações de sequenciador. Isso levanta importantes questões de governança técnica: como pode a comunidade verificar se os sequenciadores calculam as taxas STRK de acordo com estas cotações do oráculo?

Para transparência, as cotações do oráculo devem estar disponíveis publicamente, permitindo a verificação pela comunidade dos cálculos das taxas do sequenciador. Embora a integração do oráculo on-chain ofereça garantias mais robustas, a abordagem atual representa um compromisso pragmático que tenta equilibrar a complexidade técnica com os requisitos de confiança da comunidade.

Requisitos do Mecanismo de Inclusão Forçada

O mecanismo de Forçar Inclusão apresenta um caso de uso mais convincente para a integração de oráculos. Quando os usuários acionam a Forçar Inclusão do L1 ( para contornar os sequenciadores do L2 ), devem pagar as taxas de execução do L2 ao nível do L1. Por exemplo, a função depositTransaction da Optimism queima gás de acordo com o limite de gás do L2 especificado, cobrando efetivamente ETH no L1. Da mesma forma, a requestL2Transaction da zkSync calcula os custos básicos de transação do L2 e requer ETH suficiente na transação do L1.

Se esses protocolos de Camada 2 implementarem pagamentos de taxas em tokens nativos, os mecanismos de Inclusão Forçada enfrentam um desafio técnico crítico: como determinar de forma justa as taxas de ETH na Camada 1 para transações que normalmente custariam tokens da Camada 2? Sem taxas de câmbio precisas, isso poderia penalizar injustamente os usuários de Inclusão Forçada através de taxas excessivas ou permitir que atacantes explorassem taxas artificialmente baixas.

Este cenário específico apresenta um caso de uso convincente para a integração de oráculos - permitindo que os contratos L1 calculem de forma justa as taxas para transações de Inclusão Forçada.

Alternativamente, os protocolos de Camada 2 poderiam padronizar os seus tokens nativos tanto para transações regulares quanto para transações de Força de Inclusão, eliminando a necessidade de conversão entre moedas. No entanto, os custos de disponibilidade de dados permanecem denominados em ETH, criando um modelo híbrido de taxas onde as transações de Força de Inclusão requerem tanto ETH ( para dados) quanto tokens de Camada 2 ( para execução) - um desafio técnico que os desenvolvedores de Camada 2 devem enfrentar ao implementar modelos de taxas com tokens nativos.

Síntese Técnica

• Os tokens nativos da Camada 2 podem servir várias funções técnicas, com o pagamento de taxas representando uma expansão significativa de utilidade além da governança.

• A principal vantagem dos modelos de taxas de token nativo é estabelecer uma utilidade clara do token com potenciais mecanismos deflacionários através da implementação do EIP-1559.

• As desvantagens técnicas incluem maior exposição ao risco do sequenciador, fricção na experiência do usuário e barreiras de interoperabilidade em todo o ecossistema L2.

• Modelos de taxa híbridos que suportam tanto ETH como tokens nativos podem preservar a experiência do usuário e a interoperabilidade, ao mesmo tempo que permitem a utilidade do token.

• StarkNet está a liderar uma abordagem híbrida com suporte a taxas de token STRK, implementando feeds de preços de oráculo off-chain para sequenciadores.

• A autoridade do sequenciador continua a ser uma consideração técnica fundamental - os sequenciadores mantêm um poder significativo sobre a inclusão de transações e a determinação de taxas, restringido apenas pelas taxas máximas especificadas pelo utilizador.

• A integração com Oracle oferece benefícios limitados para transações padrão, mas torna-se criticamente importante para os mecanismos de Força de Inclusão, onde a conversão entre moedas afeta a segurança e a equidade.

• Implementações de Inclusão Forçada com taxas de token nativo criam desafios técnicos complexos, potencialmente exigindo que os usuários paguem tanto ETH ( por disponibilidade de dados ) quanto tokens L2 ( por taxas de execução ) em uma única transação.