Se ainda não leu a Parte I da série Como Tornar os Tokens de Cadeia Cruzada Fungíveis Novamente, pode quererverificaprimeiro, explica por que os tokens bridge perdem fungibilidade e os desafios que isso cria. Na Parte II, exploramos o ERC-7281, um novo padrão que simplifica as transferências de tokens entre cadeias, melhora a confiabilidade e dá aos emissores maior controle.

A Necessidade de Uma Abordagem Melhor

Até agora, explorámos várias soluções para o problema de tornar os tokens bridged fungíveis e resolver questões em torno da fragmentação da liquidez e da fraca experiência do utilizador das representações não canónicas de um token nativo a circular em blockchains não nativos:

• Representações canônicas da Casa da Moeda de um token em cadeias remotas através de pontes canônicas rollup/sidechain
• Criar representações canônicas de um token em cadeias remotas através de um serviço de ponte de terceiros
• Criar representações canônicas de um token em cadeias remotas através de um serviço de ponte canônica operado pelo emissor do token

Cada uma dessas abordagens exibe compensações, então é justo que a proposta do ERC-7281 para criar tokens fungíveis em ponte tente tirar o melhor de cada abordagem para criar uma solução mais holística, eficiente e acessível para protocolos que desejam implantar tokens entre cadeias sem negociar segurança, soberania ou experiência do usuário.

ERC-7281: Tokens Soberanos Interligados é uma proposta para permitir a criação de representações canônicas de um token que sejam compatíveis e fungíveis com representações cunhadas por muitas pontes diferentes. O ERC-7281 funciona estendendo a interface ERC-20 para incluir:

• Funcionalidade para criar e destruir tokens ERC-20 canônicos;
• Capacidade do proprietário do token para

1) atribuir operadores de ponte para criar e queimar tokens ao serem transferidos entre cadeias;

2) Limitar a taxa de cunhagem e queima de tokens para cada operador de ponte aprovado, por exemplo, definindo limites pequenos para pontes centralizadas e limites mais altos para protocolos mais seguros.

Dada a ligeira diferença entre os tokens ERC-721 e ERC-20, os autores do EIP descreveram os primeiros como "xERC-20". Para os leitores que necessitam de uma visão geral dos tokens ERC-20, a OpenZeppelin tem um ótimo guia sobre o tema.

Em essência, cada contrato de token ERC-20 implementa a interface ERC-20 que define um fornecimento global de token e armazena informações sobre quais endereços possuem o token e quanto eles possuem. O ERC-20 também inclui funções úteis para gerenciar o acesso aos tokens de um usuário (por meio de aprovações) e recuperar informações sobre um token, como o fornecimento total circulante e o saldo de um determinado endereço.

Uma funcionalidade adicional que o ERC-7281 adiciona à especificação do ERC-20 é uma Lockbox opcional que funciona como um contrato wrapper (semelhante ao contrato WETH (Wrapped Ether)). O contrato Lockbox envolve tokens ERC-20 em tokens xERC-20 através de mecanismos familiares de mint-and-burn e torna o ERC-7281 compatível com contratos de tokens ERC-20 existentes que não possuem uma interface de burn/mint e não são atualizáveis.

Usando o framework introduzido no artigo anterior, podemos categorizar o ERC-7281 como uma abordagem de "confiar no emissor do token + confiar no provedor de ponte (aprovado)" para emitir tokens multichain. Um token ERC-7281 implantado em várias cadeias é controlado pelo seu emissor (ao contrário de designs alternativos de tokens de cadeia cruzada que geralmente exigem renunciar à soberania). Embora o emissor ainda esteja exposto ao risco de um provedor de ponte aprovado sofrer um incidente de segurança, o emissor gerencia esse risco escolhendo manualmente e limitando a taxa de provedores de ponte autorizados.

A grande diferença, que exploraremos neste relatório, é que os emissores de tokens podem calibrar a exposição a hacks e exploits de pontes impondo limites dinâmicos sobre quantos tokens um determinado operador de ponte pode cunhar/queimar. O ERC-7281 também permite que um emissor de token coloque vários provedores de ponte na lista de permissões para cunhar o mesmo token canônico em cadeias, reduzindo a dependência de um único provedor para processar operações de ponte entre cadeias.

Ambas as características tornam o ERC-7281 uma melhoria significativa em relação às abordagens tradicionais para facilitar a cadeia cruzada de tokens de um protocolo e têm efeitos positivos de segunda ordem para os utilizadores, fornecedores de infraestruturas de interoperabilidade (especialmente agregadores) e desenvolvedores de aplicações. Após discutir as especificações na próxima seção, iremos rever as vantagens e desvantagens da implementação do ERC-7281.

Uma visão geral do ERC-7281: Sovereign bridged tokens

Queimando e cunhando tokens para usuários

Na especificação, um projeto implanta um novo contrato de token compatível com ERC20 que implementa a interface IXERC20. Os operadores da ponte criam tokens para os utilizadores na cadeia de destino após queimarem um depósito na cadeia de origem. O processo de criação de tokens verifica que a quantidade de tokens não excede o limite da ponte e atualiza o fornecimento total de tokens e o limite de criação da ponte se for bem-sucedido.

Para tokens ERC-20 já existentes, uma lógica de "lockbox" é aplicada: o provedor de ponte encapsula tokens ERC-20 depositados pelos usuários em tokens xERC-20 transferindo-os para um contrato Lockbox. O Lockbox então aprova a ponte para cunhar uma quantidade equivalente de tokens xERC-20.

Os tokens xERC-20 criados por uma ponte na cadeia de destino são queimados na cadeia de origem usando a função de queima(). Este processo garante que a quantidade de tokens não exceda o limite de queima da ponte, aumenta-o e diminui o fornecimento total de tokens xERC-20. A camada de transporte da ponte reléia a mensagem de queima para o destino. O contrato da ponte no lado de destino verifica a mensagem e cria uma quantidade igual de tokens xERC-20 para o endereço do utilizador nessa cadeia. Esta criação diminui o fornecimento total de tokens e o limite de criação da ponte.

Para fazer a ponte de tokens de volta para a cadeia inicial, o operador de ponte grava tokens xERC-20 na cadeia remota, fornecendo o endereço do usuário e a quantidade de token. O recibo de gravação é transmitido para a cadeia doméstica pela camada de transporte. Se a mensagem de gravação for verificada, o operador de ponte cunha e grava novos tokens xERC-20 na cadeia inicial para o usuário. Após a validação do recibo de gravação pelo contrato de token, o operador de ponte libera os tokens ERC-20 depositados para o usuário. A queima de tokens xERC-20 na cadeia doméstica reduz o fornecimento total do token e o limite de gravação da ponte.

Um ponto importante: o contrato xERC-20 pode tecnicamente criar tokens sem que a ponte verifique as provas. Descrevemos a abordagem padrão (leia-se: esperada), mas pontes que não implementam nenhum tipo de verificação de mensagem - ou implementam mecanismos inovadores para verificar mensagens de cadeia cruzada - podem ser incluídas na lista branca para criar e queimar tokens xERC-20. Tudo depende do que o emissor do token pode aceitar.

Limites de taxa para criação e queima de tokens

A função setBridgeLimits é uma função protegida que só pode ser chamada pelo proprietário do contrato de token. Esta função permite definir o endereço do contrato de ponte e especificar a quantidade máxima de tokens que a ponte pode cunhar (mintingLimit) e gravar (burningLimit) para os usuários. O proprietário pode atualizar esses limites, permitindo ajustar as capacidades da ponte conforme necessário. Por exemplo, se forem descobertos problemas de segurança na infraestrutura de um provedor de ponte, o mintingLimit pode ser reduzido para minimizar o risco. Por outro lado, melhorias de segurança podem levar a um aumento no limite de cunhagem.

A especificação xERC-20 também inclui funções para verificar os limites de queima e cunhagem para pontes aprovadas para lidar com o token. "mintingMaxLimitOf" retorna a quantidade máxima de tokens que uma ponte pode cunhar e, respectivamente, "burningMaxLimit" retorna a quantidade máxima de tokens que uma ponte pode queimar durante um período especificado. Além disso, essas funções mostram os tokens restantes que uma ponte pode queimar e cunhar antes de atingir os limites predefinidos.

Estas funções de visualização são úteis para os agregadores de pontes que precisam de saber os limites disponíveis para diferentes fornecedores de pontes antes de encaminhar transações. Se uma ponte atingir o seu limite de queima ou cunhagem na cadeia de origem ou de destino, isso pode afetar transações em curso e a experiência do utilizador. Portanto, os agregadores preferem encaminhar pedidos para pontes que ainda não atingiram os seus limites de cunhagem e queima e podem realizar a troca de uma determinada quantia.

Parâmetros de limite de taxa

A especificação da interface do token xERC-20 inclui uma estrutura “Bridge” contendo “burningParams” e “mintingParams” (os parâmetros de controle da função de limite de taxa de um token xERC-20 controlam quantos tokens uma ponte pode queimar e criar em um período predefinido). “maxLimit” define o limite máximo de criação e queima de tokens e aumenta a cada segundo a uma taxa predefinida (“ratePerSecond).”

Aqui é onde abordamos um possível ponto de confusão: “maxLimit” (definido tanto para o limite de queima quanto para o limite de cunhagem) soa como um limite na cunhagem e operações de queima em uma escala de tempo específica — não um limite de taxa que controla a cunhagem e queima de acordo com os limites predefinidos durante a janela de tempo pré-definida. “currentLimit” define quanto uma ponte pode cunhar ou queimar e aumenta a uma taxa predefinida. Em contraste, “maxLimit” define quanto uma ponte pode cunhar ou queimar diariamente.

Os parâmetros de queima e cunhagem são principalmente relevantes para os proprietários de tokens (e em menor medida para os operadores de pontes). No entanto, os parâmetros de limite máximo e atual são considerações importantes para os usuários e operadores de pontes. Por exemplo, o limite atual pode afetar quanto um usuário pode tranquilamente fazer a ponte com um protocolo de cadeia cruzada sem enfrentar atrasos na receção de tokens xERC-20 no destino.

Cofre xERC-20

O token ERC-20 original não especifica funções para aumentar e diminuir o fornecimento de um token (quando “tokenomics” significava gerar um número fixo de tokens e dizer aos usuários que o token tinha valor porque seria escasso em poucos anos*). Portanto, nem todo token ERC-20 possui uma função de cunhagem e queima. Uma vez que o ERC-7281 utiliza o mecanismo de cunhagem e queima preferido pela maioria (se não todos) das pontes hoje em dia, tokens ERC-20 legados ou não-atualizáveis não podem funcionar diretamente com o ERC-7281.

O contrato Lockbox fornece uma solução alternativa e possibilita a compatibilidade com tokens existentes. Na especificação original (ou seja, um projeto implementa um novo contrato de token que executa a interface IXERC20), os operadores da ponte só precisam chamar mint() para criar tokens para um usuário na cadeia de destino (após bloquear um depósito na cadeia de origem).

O contrato Lockbox pega muito emprestado do design do contrato de wrapper WETH. Ele implementa uma função deposit() para depositar o token ERC-20 correspondente no Lockbox e uma função withdraw() para operadores de ponte desbloquearem tokens ERC-20 depois de queimar tokens empacotados em um domínio remoto.

Os dois primeiros tipos de erro destacados na especificação ("IXERC-20Lockbox_NotNative" e "IXERC-20Lockbox_Native") ocorrem quando um usuário tenta depositar tokens no contrato Lockbox errado. Um Lockbox pode ser nativo ou não nativo, dependendo dos tipos de tokens suportados.

Os Lockboxes nativos guardam tokens nativos, ou seja, tokens usados para pagar taxas de gás aos validadores. Um exemplo de um token que teria um Lockbox nativo para envolvê-lo em um token xERC-20 é ETH: envolver ETH em um token xERC-20 exigiria chamar a função depositNative() do Lockbox e depositar ETH para receber a representação compatível com ERC7281 de ETH.

As caixas de depósito regulares (não nativas) custodiam tokens ERC-20 como USDC, DAI, WETH, USDT, etc. Para criar USDC como um token xERC-20, por exemplo, o utilizador chamaria deposit() no contrato da caixa de depósito após bloquear USDC.

Chamar deposit() com ETH resultaria em que esses fundos fossem bloqueados para sempre, uma vez que o contrato Lockbox regular só pode envolver e desembrulhar tokens ERC-20. Chamar depositNative() com um token ERC-20 produziria resultados semelhantes, já que os contratos nativos do Lockbox devem funcionar com tokens nativos, não com tokens ERC-20.

Desta forma, ao envolver tokens canônicos ERC-20 em tokens xERC-20 com suporte a hortelã/gravação, o Lockbox fornece uma camada de compatibilidade importante para o padrão. No entanto, para alguns casos, como integrar outras soluções de ponte no xERC-20, usar apenas o cofre e retornar o token encapsulado não é uma opção. Por esse motivo, os projetos podem implementar contratos de adaptador.

Contratos de adaptador

Nos casos em que os protocolos de ponte não são projetados para reconhecer as operações inerentes aos tokens xERC-20 (criar/queimar, registo correspondente e tal), as aplicações podem construir contratos adaptadores. Estes contratos funcionam como invólucros e desinvólucros automatizados - traduzindo eficazmente o comportamento padrão de aprovação + chamada do ERC-20 para um esquema de criar/queimar mais sofisticado requerido pelo xERC-20.

Isto é necessário porque muitos protocolos de ponte (por exemplo, o CCIP da Chainlink) continuam otimizados para o comportamento convencional do ERC‑20. O contrato do adaptador pode preencher (ba-dum-tss) esta lacuna de compatibilidade ao consagrar tal lógica: deposita tokens na Caixa de Bloqueio para gerar a representação xERC‑20 na cadeia de origem e, mais tarde, após a receção da mensagem na cadeia de destino, desencadeia o mecanismo de retirada para reverter para o ativo canónico.

Este fluxo garante que o utilizador receba, em última instância, um token consistente e canónico — não afetado pelos mecanismos de embalagem alimentados por xERC-20 sob o capô. Desta forma, os adaptadores podem permitir que os protocolos se integrem perfeitamente com pontes não compatíveis com xERC-20 e aumentem o espectro de soluções interoperáveis que suportam.

Porque ERC-7281? O caso de um padrão de token ponte soberano

A um nível elevado, o ERC-7281 tem quatro grandes objetivos:

1. Fungibilidade: Os usuários que fazem a ponte entre tokens da cadeia nativa do token para outra cadeia (L1/L2) devem sempre receber representações canônicas do token em ponte no destino. Várias versões não fungíveis do mesmo token circulando em uma cadeia não nativa são problemáticas por razões explicadas anteriormente (por exemplo, fragmentação de liquidez e fraca composição de tokens).

A visão original para criar a especificação ERC-20 era garantir fungibilidade e interoperação perfeita entre tokens no Ethereum entre aplicativos e infraestrutura Ethereum. No entanto, depois de adotar um roteiro de escalonamento centrado no rollup, surgiu o problema da falta de composabilidade atômica, e a criação de muitos domínios diferentes degradou essas propriedades de fungibilidade. O xERC-20 permite agregar a liquidez de várias pontes cross-rollup em tokens multi-rollup unificados, restaurando a visão inicial do Ethereum.

1. Segurança: Para reduzir o risco de contraparte, os emitentes de tokens devem ter a opção de selecionar entre fornecedores de pontes concorrentes de acordo com a avaliação da infraestrutura de segurança. Além disso, os emissores de tokens devem ter proteção significativa contra as consequências de incidentes de segurança que afetam provedores de ponte parceiros — ataques isolados em um ou dois serviços de ponte não devem eliminar TVLs inteiras.

2. Inicialização livre de liquidez para tokens de cadeia cruzada: DAOs de protocolo não devem ser forçados a gastar recursos (financeiros) significativos na liquidez de inicialização para tokens em ponte como parte dos planos de expansão de várias cadeias. Não só a ponte baseada em liquidez é ruim para a UX, mas os gastos com incentivos de provisão de liquidez podem se tornar inviáveis para as equipes de projeto à medida que o número de blockchains aumenta em breve.

3. Soberania para emissores de tokens: O emissor de tokens deve permanecer no controle da representação canônica de tokens de protocolo cunhados em cadeias não nativas. Resolver o problema de tokens ponte não fungíveis não deve exigir a transferência do controle de um token ponte de um projeto, especialmente aspectos administrativos como controlar o fornecimento total e configurar mecanismos de cunhagem e queima, para uma ponte de terceiros.

Podemos expandir ainda mais esses objetivos para ver quais benefícios o ERC-7281 oferece para protocolos e comunidades.

Analisando os benefícios do ERC-7281

Melhorar a experiência do usuário e eliminar a fragmentação da liquidez

ERC-7281 resolve várias versões do problema de dependência de caminho descrito na introdução.

A dependência de caminho pode ser específica da cadeia (por exemplo, ETH ponteada do Ethereum → Arbitrum → Otimismo é diferente do ETH ponteado do Ethereum → Otimismo → Arbitrum) ou específica da ponte (por exemplo, ETH ponteado do Ethereum para o Otimismo via Celer é diferente do ETH ponteado do Ethereum para o Otimismo via Connext).

A dependência do caminho é uma funcionalidade de segurança valiosa, mas também pode ser prejudicial para a interligação UX e a composabilidade de cadeias cruzadas. Por exemplo, um usuário não pode fornecer liquidez programaticamente a um DEX de cadeia cruzada que opera na Optimism e Arbitrum, uma vez que a aplicação deve aceitar opETH ou arbETH.

O ERC-7281 elimina o problema introduzindo tokens xERC-20 que permanecem fungíveis, não importa quantas vezes um usuário faça pontes entre cadeias ou quais provedores de ponte estejam acostumados a unir tokens. Suponha que um usuário deseje mover USDT embrulhado de Arbitrum para Optimism sem se retirar para Ethereum primeiro; um provedor de ponte pode queimar tokens xERC-20 no Arbitrum e mint xERC-20s no Optimism — o valor dos tokens cunhados no Optimism ainda está atrelado aos tokens depositados no Lockbox e são remapeados para manter seu suporte 1:1.

É importante ressaltar que o ERC-7281 oferece os benefícios de implantar um token em ponte canônico como o CCTP (Cross-Chain Transfer Protocol) da Circle sem exigir que o protocolo tenha custódia centralizada de tokens em ponte. Por exemplo, a liquidez é consolidada em torno da representação canônica do token de um projeto, o que melhora a utilidade do token para aplicativos DeFi e reduz a sobrecarga de criar mercados diferentes para diferentes versões do mesmo ativo.

Reforço da soberania dos emissores de tokens

Os xERC-20s são descritos como "tokens de ponte soberana", pois os emissores de tokens não estão presos ao uso de uma opção específica para cunhar representações canônicas de um token e manter o controle do design e administração de tokens em ponte entre implantações. O ERC-7281 é um híbrido entre "cunhar tokens canônicos por meio de uma ponte de terceiros" e "cunhar tokens canônicos por meio de uma ponte controlada pelo emissor de tokens" que combina soberania, experiência do usuário e descentralização no mesmo pacote.

Projetos que implementam tokens cadeia cruzada com ERC-7281 podem criar representações canônicas de tokens nativos via várias pontes sem enfrentar o problema de versões embrulhadas não fungíveis do mesmo ativo nativo, quebrando a UX para usuários que esperam alavancar a composabilidade e fungibilidade de tokens ERC-20. Tais projetos também mantêm um nível semelhante de controle sobre implementações de token cadeia cruzada como um emissor de token que executa infraestrutura interna para gerenciar transferências de tokens canônicos entre domínios, uma vez que os contratos de token xERC-20 e o Lockbox - que as pontes utilizam para travar, criar e queimar tokens para os usuários - são implementados e controlados pelo projeto.

Este recurso discreto pode ser útil em casos em que um projeto de alto perfil tem um token nativo emitido na cadeia doméstica. Utilizadores de outros ecossistemas desejam exposição ao token sem o deter na sua cadeia nativa por diferentes motivos.

Ainda assim, o projeto não tem a capacidade ou a vontade de executar infraestrutura de ponte interna para cada cadeia para garantir compatibilidade 1:1 entre tokens em ponte — nem quer transferir o controle de seu token para um terceiro não necessariamente alinhado com o protocolo e sua comunidade. Tal caso torna-se uma consideração ao implementar a governança de cadeia cruzada que permite votar com tokens em ponte enquanto os votos são computados na cadeia nativa; Um provedor de ponte não alinhado com controle de tokens em ponte torna-se um ponto de estrangulamento para a governança de protocolo.

Beefy, um protocolo de agricultura de rendimento, também adotou xERC-20 por este motivo. Como a documentação de ponte do projeto descreve, o ERC-7281 forneceu ao projeto mais opções para tokens de ponte – que se tornaram necessários depois que um grande parceiro de ponte sofreu um hack (um tema que está rapidamente se tornando familiar para os nativos de criptomoedas) – e forneceu um controle mais refinado do design de mecanismos de ponte. No caso da Beefy, o recurso de listagem de permissões do ERC-7281 permitiu que o protocolo selecionasse vários parceiros de ponte e oferecesse aos usuários diferentes opções entre otimização para velocidade, descentralização, custos e segurança ao unir tokens mooBIFI.

A realinhamento de incentivos melhora a competição aberta e a segurança

A ponte baseada na liquidez muitas vezes favorece projetos com capacidade financeira para gastar em incentivos de liquidez - já que os emissores de tokens desejam gastar pouco em incentivos de LP e oferecer uma UX de ponte superior, a liquidez se torna o fator mais crucial para os protocolos que usam pontes canônicas L1/L2. Isso também se estende à seleção de provedores de ponte por agregadores de ponte, tornando, sem dúvida, mais difícil para novos serviços de ponte (mesmo aqueles com infraestrutura segura) competir com protocolos de ponte mais estabelecidos.

O ERC-7281 resolve o problema eliminando a necessidade de pontes baseadas na liquidez. Sem a necessidade de cunhar e trocar tokens não canônicos por tokens canônicos, pontes de qualquer tamanho podem ser aprovadas para cunhar o token de um projeto em um domínio remoto. Como os emissores de tokens querem minimizar a exposição a falhas de ponte, mais protocolos provavelmente começarão a prestar mais atenção aos projetos de segurança de pontes de cadeia cruzada em vez de se concentrar na liquidez primeiro.

Isso incentiva a competição aberta, tornando-se um caso de "deixe a ponte mais segura ganhar" e não "deixe a ponte mais líquida ganhar"; essa competição aberta pode assumir a forma de pontes competindo em mais recursos além de liquidez/segurança (por exemplo, taxas, APIs/SDKs, integrações de aplicativos, etc.). Esses recursos são, sem dúvida, mais fáceis de incorporar em um aplicativo desde o início, uma vez que dependem principalmente da expertise da equipe de desenvolvimento; por outro lado, a liquidez e os volumes de interligação são mais complexos de inicializar e requerem uma mistura de desenvolvimento de negócios, financiamento, conexões industriais, marketing e muito mais.

Melhor gestão de risco para emissores de tokens

O ERC-7281 introduz um limite de taxa configurável para cunhagem e gravação de tokens que melhora drasticamente o perfil de risco para protocolos que trabalham com pontes de terceiros para cunhar tokens canônicos em cadeias não nativas. Se um provedor de ponte parceiro for hackeado ou comprometido, o maior dano que um invasor pode causar é equivalente ao limite atribuído à ponte comprometida. Se um emissor de token escolher parâmetros de limitação de taxa cuidadosamente, ataques isolados em uma ponte devem ter impacto mínimo na solvência do protocolo.

A configuração de limites de taxa por ponte também pode melhorar o processo de avaliação de risco para DAOs de protocolo. Atualmente, a avaliação de risco de ponte pode levar meses para ser concluída devido à magnitude do impacto de uma ponte canônica de terceiros ser hackeada; Os protocolos querem garantir a tomada de decisões defensáveis, onde a segurança da ponte escolhida é examinada extensivamente para dar à comunidade garantias mais fortes de segurança. Além de ser desnecessariamente um desperdício de esforço e tempo, a maratona de análises de segurança de pontes ainda não garante que uma ponte escolhida seja imune a explorações de dia zero.

A adoção do ERC-7281 torna a avaliação de riscos mais dinâmica. Os projetos ainda têm que completar a devida diligência sobre os provedores de pontes para escolher propriedades apropriadas de limitação de taxa; no entanto, os prazos de avaliação de riscos podem ser reduzidos para refletir que os protocolos já não estão numa posição de tudo ou nada. Em vez de passar meses analisando várias pontes para escolher uma opção, um projeto pode passar metade do tempo escolhendo inicialmente vários provedores de pontes e definindo limites de cunhagem variados com base numa avaliação de segurança. O emissor do token pode então realizar revisões de segurança para determinar se deve aumentar ou diminuir os limites de cunhagem para parceiros de pontes selecionados ou retirar os direitos de cunhagem de uma ponte (por exemplo, em resposta a um hackeamento ou divulgação de vulnerabilidade).

O ERC-7281 também reduz a barreira para projetos que desejam optar por avanços de ponta em segurança de pontes, mas hesitam em adotar uma tecnologia específica em sua totalidade até que a tecnologia tenha sido testada e examinada rigorosamente pela comunidade (ou seja, o dilema do inovador). Suponhamos que um provedor de ponte proponha uma nova infraestrutura que supostamente melhore substancialmente as garantias de segurança. Nesse caso, um protocolo pode "testar as águas" atribuindo direitos de cunhagem limitados à ponte e aumentando progressivamente o limite de cunhagem da ponte à medida que aumenta a confiança no projeto do sistema proposto.

Assim como remover preocupações relacionadas à liquidez, remover a necessidade de um protocolo para confiar 100% na pilha de tecnologia de uma ponte antes de atribuir direitos de cunhagem cria concorrência igual entre novos participantes e antigos jogadores – os antigos jogadores têm o incentivo para iterar em melhores abordagens de segurança, uma vez que os emissores de tokens agora têm a flexibilidade de retirar direitos de cunhagem e reatribuir a um projeto menor apenas porque este último demonstrou um maior compromisso com a segurança e a descentralização. Isso também elimina outro fator de risco para protocolos que trabalham com pontes de terceiros: o risco de que um provedor de ponte selecionado pare de inovar em segurança, apesar do ritmo rápido em que falhas e problemas na segurança de ponte são divulgados e descobertos porque sabe que o emissor do token não pode impor ações punitivas (por exemplo, migrar para outro provedor de ponte) devido à dificuldade de executar tais atividades.

Melhorar a composição entre ecossistemas

A criação de fluxos de trabalho de aplicativos complicados que exigem tokens de roteamento através de qualquer número de cadeias é difícil hoje devido ao preço imprevisível de pontes baseadas em liquidez. Por exemplo, um agregador de ponte entre Ethereum → Linea → Base tem duas opções:

1. Defina um parâmetro de tolerância de deslizamento e execução de preço de roteamento entre cadeias com base na quantidade mínima de tokens que um usuário receberá em cada cadeia (dependendo da quantidade de liquidez disponível quando a mensagem de ponte chegar a cada camada).
2. Não defina um parâmetro de tolerância de derrapagem; em vez disso, crie lógica para obter liquidez on-chain (por exemplo, através de DEXes) se a quantidade de tokens recebidos em uma ou mais cadeias for menor do que a quantidade esperada.

Em comparação, os agregadores de pontes podem saber antecipadamente quantos tokens devem esperar em cada domínio envolvido numa transação de cadeia cruzada, verificando mintingLimit e burningLimit para pontes autorizadas a criar um token específico. Admitidamente, uma ponte pode atingir o maxLimit entre o momento em que a transação é transmitida e a transação chega a um domínio - o que significa que o utilizador não pode receber tokens canónicos no destino.

No entanto, o ERC-7281 continua a ser uma melhoria a este respeito pelas seguintes razões:

1. Se um operador de ponte atingir MintingLimit enquanto uma transação estiver em andamento, a transação de ponte será mantida e tentada novamente mais tarde quando os parâmetros do limite de taxa forem ajustados. Os usuários não recebem uma representação proprietária embrulhada do token canônico — ao contrário das pontes de liquidez atuais.
2. Os agregadores de pontes têm mais previsibilidade sobre quando uma transação de ponte será executada e o número de tokens a esperar. Como mintingLimit e burningLimit estão configurados para usar blocos como medida de tempo (como mostrado na seção sobre parâmetros de limitação de taxa), é fácil calcular quando uma ponte começará a criar e queimar tokens novamente; em contraste, prever quando a liquidez aumentará em uma ponte é o equivalente a jogar roleta russa.

Mudanças imprevisíveis na liquidez também significam imprevisibilidade na precificação de transações de transição repetidas. Suponha que um agregador de ponte (ou outro aplicativo) coloque uma cotação para um swap de cadeia cruzada com base no preço atual de um par de tokens no pool de liquidez de uma ponte (esse preço é baseado na liquidez total do pool). Ainda assim, a transação não pode ser executada devido a uma queda acentuada na liquidez do pool. Suponha que a negociação seja realizada e tentada novamente mais tarde. Nesse caso, o desenvolvedor do aplicativo não pode saber se a cotação anterior permanece precisa ou se a liquidez atingirá os mesmos níveis de quando o usuário enviou a transação pela primeira vez.

Uma vez que a ponte de tokens xERC-20 não está sujeita a movimentos de liquidez, os utilizadores podem ter a certeza de que as transações entre cadeias não incorrerão em deslizamento, mesmo que não sejam executadas imediatamente.

Os agregadores de pontes não são os únicos a beneficiar desta melhoria na capacidade de composição; qualquer aplicação de cadeia cruzada pode aproveitar a fungibilidade dos tokens xERC-20 para criar aplicações mais interessantes. Isso é mais difícil hoje devido a problemas em torno da dependência de caminho: suponha que um desenvolvedor deseje fazer a ponte entre ETH e Ethereum, abrir uma posição de empréstimo em um DEX Arbitrum e usar os lucros para comprar um NFT no Optimism antes de voltar para o Ethereum. Aqui, o desenvolvedor deve garantir a integração com provedores de ponte nessas cadeias — já que você não pode facilmente trocar versões proprietárias — o que não é o caso quando os tokens em ponte de um projeto são fungíveis após a adoção do xERC-20.

Esse fluxo de trabalho é semelhante às pontes de emissor de token descritas anteriormente. Tomemos o Circle CCTP como exemplo:

O Cross-Chain Transfer Protocol da Circle permite que os usuários tenham uma versão unificada e canônica de seu token USDC sem ficarem presos no ecossistema de suas cadeias. Todas as transferências entre cadeias são processadas através do seu protocolo usando o esquema burn-and-mint.

No entanto, enquanto o CCTP é um protocolo centralizado, uma vez que os operadores da Circle são as únicas entidades autorizadas a queimar e criar os seus tokens USDC, o xERC-20 liquidiza o risco de confiança ao permitir que várias entidades com vários mecanismos de segurança operem transferências de cadeia cruzada.

Apoiar a visão da Ethereum de um futuro centrado em rollup e multichain

O ERC-7281 pode acelerar o roteiro centrado no rollup do Ethereum, dando aos projetos a confiança para implantar tokens em novos EVM L2s que podem não ter os fortes perfis de segurança das cadeias L2 estabelecidas. Por exemplo, a ponte canônica de um rollup de estágio 0 é menos segura, uma vez que o Ethereum L1 não garante a segurança da ponte. Um projeto de token pode ser lançado lentamente para tal cadeia, concedendo direitos de cunhagem limitados para a ponte canônica e aumentando o limite de cunhagem quando o rollup avança para o estágio 1.

Este processo pode continuar até que o L2 atinja o estágio 2 (o estágio mais alto de descentralização e segurança para um rollup). Um mecanismo pelo qual os protocolos podem ser implantados em cadeias recém-lançadas de forma minimizada ao risco beneficia o ecossistema Ethereum, tornando mais fácil para os novos L2s inicializarem a liquidez e os aplicativos do token, ao mesmo tempo em que incentiva mais inovação dentro do espaço de design de rollup.

Potenciais inconvenientes da aplicação do ERC-7281

Aumento das despesas gerais para as equipes de gerenciamento de projetos DAO

Embora o ERC-7281 seja muito atraente para os protocolos, as DAOs podem hesitar em adotar tokens xERC-20 devido ao significativo custo operacional que as equipes de projetos DAO devem incorrer para gerir os tokens xERC-20 em várias implementações.

Gerard Persoon's Gerir tokens em pontes em um grande número de cadeias inclui uma lista não exaustiva de tarefas únicas e recorrentes que o protocolo deve realizar após a migração do ERC-20 para o xERC-20:

Essa é uma lista muito longa de tarefas

Uma solução proposta é que as DAOs terceirizem algumas dessas tarefas administrativas relacionadas ao gerenciamento de tokens xERC-20 cross-chain para serviços de terceiros, mas isso é apenas trocar uma compensação (custos de recursos humanos) por outra (custos de contratação de serviços).

Suponha que um protocolo gerenciava anteriormente tokens de cadeia cruzada com infraestrutura interna (por exemplo, implantando um contrato de token separado por cadeia e controlando a emissão e queima). Nesse caso, o ERC-7281 não parece uma mudança radical. No entanto, projetos acostumados a terceirizar o gerenciamento da infraestrutura central de ponte para equipes de desenvolvimento de pontes acharão a carga de trabalho adicional preocupante.

Por exemplo um membro da equipa principal do Lido delineado(em resposta a uma proposta para a Lido implementar wstETH como um token xERC-20 em todas as implementações) as responsabilidades atuais da equipa de PM preocupada com a infraestrutura de interoperabilidade e contrastou o conjunto com o conjunto de responsabilidades que os mesmos membros da equipa teriam de assumir se a Lido DAO votasse para que todos os domínios com wstETH migrassem para uma versão xERC-20.

Como a conversa acima mostra, gerir tokens xERC-20 impõe um aumento não negligenciável nos encargos administrativos para os protocolos e membros da comunidade. Por exemplo, os limites da ponte requerem monitorização ativa e avaliação da segurança da ponte para informar ajustes aos limites de cunhagem, e as decisões sobre os limites da ponte (ou retirada/atribuição de direitos de cunhagem) podem estar sujeitas a uma votação da DAO (se tais escolhas precisarem de ser feitas frequentemente, os membros da DAO podem sofrer de fadiga de votação).

No entanto, isto não deve ser interpretado como um juízo de valor sobre o ERC-7281. Cada projeto terá diferentes perfis de risco, objetivos de longo prazo e recursos — e esses fatores determinam coletivamente se o benefício a longo prazo da adoção do ERC-7281 supera os custos de curto prazo e contínuos de fazê-lo.

Por exemplo, projetos menores podem achar mais difícil gerir os custos administrativos e operacionais da emissão de tokens xERC-20 e optar por um serviço gerenciado de ponte de tokens multichain, como o ITS (Interchain Token Service) da Axelar ou o NTT (Native Token Transfers) da Wormhole. Projetos mais estabelecidos podem ter recursos para gerir os custos administrativos e operacionais da emissão de um token xERC-20 e podem considerar o controle proporcionado pelo ERC-7281 valer a sobrecarga adicional de gerir tokens de cadeia cruzada.

Dificuldades em torno da migração de tokens existentes para o padrão xERC-20

Para projetos que não têm uma interface mint/burn, ou não podem atualizar contratos de token para usar IERC20 via herança, e já têm representações canônicas de tokens nativos circulando em cadeias não nativas, migrar para tokens xERC-20 é um processo longo que requer uma grande coordenação e envolve uma complexa rede de participantes — desde detentores de tokens, trocas (DEXes e CEXes), pontes de parceiros e aplicativos integrados com o token ERC-20 legado. Mesmo com essa parte tratada, os protocolos ainda suportam o custo de desembrulhar ERC-20s em xERC-20s para concluir o processo de migração.

Conforme explicado na discussão da especificação ERC-7281, os tokens existentes precisarão ser bloqueados na Lockbox para criar xERC-20s para os usuários. O encerramento do legado ERC-20 acontece logo depois e envolve outro processo prolongado de comunicação com a comunidade sobre o cronograma para congelar a criação de novos tokens ERC-20 (legado). Novamente, isso pode valer a pena do ponto de vista do protocolo, embora os benefícios também possam ser insuficientes para justificar os custos de coordenar uma migração em toda a ecossistema para a representação compatível com xERC20 de um token de protocolo.

Superfície de risco maior para a governação da DAO

O gerenciamento de tokens xERC-20 em vários domínios com o ERC-7281 requer governança ativa da DAO supervisionando o protocolo. Isso envolve a definição de parâmetros como limites de cunhagem, atualização do contrato Lockbox e pausa de cunhagem ou gravação de tokens. Estas decisões são sensíveis em termos de segurança e devem ser regidas pela DAO para evitar a responsabilidade das decisões em salas de reuniões fechadas.

O ERC-7281 visa dar aos protocolos controle sobre essas decisões, em vez de pontes de terceiros. Isso faz sentido, pois as DAOs já gerenciam tokens em suas cadeias nativas, portanto, estender sua governança para tokens em outras cadeias é razoável para protocolos e comunidades que buscam esse controle. No entanto, alguns protocolos podem não querer esse controle DAO extra devido a preocupações com governança e estabilidade.

Por exemplo, projetos de alto perfil como o Lido enfrentam escrutínio sobre questões de governança. Adicionar controle sobre o gerenciamento de tokens aumenta o risco de uma aquisição de governança. Um ataque de governança pode ter efeitos generalizados se um projeto consolidar todos os tokens ERC-20 em um Lockbox e o DAO governá-lo. Um invasor pode obter o controle do Lockbox e introduzir um provedor de ponte mal-intencionado sem limites de cunhagem, tornando os tokens xERC-20 em outras cadeias inúteis.

Este cenário tem paralelos com a exploração Multichain, onde uma vulnerabilidade na infraestrutura de assinatura de computação multipartidária (MPC) permitiu que hackers comprometessem os principais endereços Multichain que estavam custodiando tokens nativos no Ethereum e Dogecoin – esses tokens apoiados tokens cunhados em cadeias não nativas como Fantom e Moonriver, o que criou um efeito dominó que resultou em projetos em outros lugares sofrendo perdas como resultado do ataque aos contratos inteligentes da Multichain no Ethereum e Dogecoin.

Incompatibilidade com protocolos maximamente descentralizados

O ERC-7281 se encaixa na finalidade quando o token é emitido por um protocolo com governança de token ou uma entidade centralizada (por exemplo, USDC da Circle ou o Stablecoin CZKC). No entanto, não é tão valioso se o protocolo for maximamente descentralizado e carecer de governação formal—o stablecoin LUSD da Liquity é um exemplo de um token que seria difícil de tornar compatível com o padrão xERC-20.

O token xERC-20 requer que uma entidade decida sobre parâmetros específicos, como limites de cunhagem e gravação, e tome decisões como colocar certos provedores de ponte na lista de permissões ou não. Isso implica a necessidade de governança contínua para a existência do token xERC-20. Para projetos que desejam descentralizar componentes críticos do protocolo, como o contrato de token da DAO, ao longo do tempo, isso pode causar problemas e complicar os planos de descentralização.

Maior risco de exploits que afetam os componentes principais (contrato Lockbox e fornecedores de pontes)

Já mencionamos como funciona a dependência de caminho e por que ela ajuda a fornecer garantias de que uma exploração que afeta a cadeia A não afetará a cadeia B, ou que uma exploração envolvendo a ponte A na cadeia A não afetará a ponte B na cadeia B. O ERC-7281 remove a dependência de caminho, o que tem benefícios, mas também introduz uma compensação em torno da segurança:

A liquidez máxima disponível numa ponte já não representa um limite superior para o impacto potencial de uma exploração de ponte no emissor de tokens, uma vez que os tokens emitidos por diferentes fornecedores de pontes são fungíveis através de domínios. Os autores do ERC-7281 propõem escolher um limite de taxas para os fornecedores de pontes com base no montante que um emissor de tokens pode gastar para compensar as perdas resultantes da emissão fraudulenta; ainda assim, um limite de taxas selecionado pode ter sido demasiado conservador em retrospectiva.

Se uma ponte com um limite alto for comprometida, os efeitos podem ser pronunciados, mesmo para usuários de outras pontes cunhando o mesmo token. Os protocolos podem reduzir o risco distribuindo direitos de cunhagem em um grande número de pontes (para que um provedor de ponte não tenha um número descomunal de tokens que pode cunhar em comparação com outras pontes), mas tentar proteger o risco dessa forma pode aumentar a ineficiência, pois cada ponte exigirá avaliação independente da equipe DAO e a coordenação com mais pontes aumenta a sobrecarga administrativa que mencionamos anteriormente.

O contrato Lockbox governado por um DAO poderia introduzir efeitos de contágio adversos no caso de um ataque de governança. Mas mesmo com uma governança segura do DAO, um bug nos contratos Lockbox nativos/não nativos na cadeia de origem do token pode causar tantos problemas (Sifu é agora o proprietário do contrato Lockbox para um projeto, e os fundos já não estão SAFU). Em comparação, este problema é reduzido no status quo, uma vez que os contratos de cofre (equivalente ao contrato Lockbox do fornecedor da ponte) apenas detêm tokens transferidos através do serviço de ponte correspondente. Assim, um bug no contrato de cofre de um fornecedor apenas afeta os utilizadores que depositaram tokens nessa ponte.

Despesas gerais para integrações de ecossistemas

O trabalho administrativo extra com o ERC-7281 também afeta os desenvolvedores de aplicativos e provedores de serviços que usam o token xERC-20 de um projeto. Os agregadores de ponte precisam acompanhar os mapeamentos entre tokens xERC-20 e seus contratos Lockbox correspondentes para evitar problemas como tokens de spam e ataques de falsificação. Embora um registro desses mapeamentos possa ajudar, configurar esse registro é um desafio sem arriscar a centralização ou expor os adotantes do xERC-20 a ameaças.

O risco vem de atacantes potencialmente adicionando contratos maliciosos ao registro de tokens e enganando usuários e desenvolvedores para enviar tokens para o endereço errado. Isso pode levar ao roubo de tokens em redes L2 e L1. As exchanges enfrentam desafios semelhantes, pois os tokens falsificados podem causar sérios problemas, como o comportamento inesperado do token, que difere dos tokens canônicos aprovados.

Conclusão

A ERC-7281 apresenta uma solução convincente para os problemas dos tokens pontuais não fungíveis e oferece funcionalidades que aprimoram a experiência do usuário, descentralização, segurança e flexibilidade nos designs de ponte de tokens. Alguns desses problemas afetam diretamente a viabilidade do roadmap centrado em rollup, tornando o padrão xERC-20 uma infraestrutura crítica para o ecossistema Ethereum L2.

Vários jogadores-chave no espaço de ponte, incluindo Hyperlane, Omni, Sygma, Router Protocol e Everclear, comprometeram-se a adotar o ERC-7281, indicando uma tração significativa para a proposta. Mesmo emissores de tokens estabelecidos (que têm mecanismos de trabalho para unir tokens) – como o Circle – mostraram interesse no ERC-7281 para enfrentar os desafios colocados por tokens não aprovados que afetam usuários e desenvolvedores.

O ERC-7281 aborda esses problemas enquanto mitiga muitas compensações associadas a abordagens anteriores para cunhar tokens canônicos em domínios remotos. Ele fornece inicialização livre de liquidez, ao contrário das pontes consagradas, não requer infraestrutura personalizada, como pontes de emissores de tokens, e evita a dependência do fornecedor ao permitir a cunhagem canônica de tokens de várias pontes por provedores de ponte aprovados.

Para aqueles interessados em seguir a discussão em torno do ERC-7281 ou desenvolvedores que procuram integrar xERC-20,a Irmandade dos Mágicos do Ethereumeo sítio Web do xERC-20são excelentes recursos. A comunidade também construiu um Lançamento xERC-20 para agregar ferramentas para criar, monitorar e gerenciar tokens xERC-20 — uma ferramenta valiosa para construtores que desejam implantar um token xERC-20 pela primeira vez ou migrar um token existente para o padrão de token xERC-20.

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

1. Este artigo é reproduzido a partir de [2077 Pesquisa]. Todos os direitos autorais pertencem ao autor original [2077 Research]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learn equipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. A equipe do Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.