Se você não leu a Parte I da série Como Tornar os Tokens Cross-Chain Fungíveis Novamente, você pode quererverifique issoPrimeiro, ele descreve por que os tokens ponte 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, aprimora a confiabilidade e dá aos emissores maior controle.

A Necessidade De Uma Abordagem Melhor

Até agora, exploramos várias soluções para o problema de tornar os tokens bridged fungíveis e resolver questões em torno da fragmentação de liquidez e da má UX das representações não canônicas de um token nativo que circula em blockchains não nativos:

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

Cada uma dessas abordagens exibe compensações, então é apenas adequado que a proposta do ERC-7281 para criar tokens ponteáveis e fungíveis 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 em cadeia cruzada sem comprometer a segurança, a soberania ou a 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 são compatíveis e fungíveis com as representações cunhadas por muitas pontes diferentes. O ERC-7281 funciona estendendo a interface ERC-20 para incluir:

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

1) atribuir operadores de ponte para cunhar e queimar tokens quando ligados entre cadeias;

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

Dada a ligeira diferença entre os tokens ERC-7281 e ERC-20, os autores do EIP descreveram o primeiro como "xERC-20". Para os leitores que precisam de uma visão geral dos tokens ERC-20, o 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 tokens e armazena informações sobre quais endereços possuem o token e quanto possuem. ERC-20 também inclui funções úteis para gerenciar o acesso aos tokens de um usuário (via aprovações) e recuperar informações sobre um token, como o fornecimento total em circulação e o saldo de um endereço específico.

Uma funcionalidade adicional que o ERC-7281 adiciona à especificação do ERC-20 é uma Lockbox opcional que funciona como um contrato de invólucro (similar ao contrato WETH (Wrapped Ether)). O contrato Lockbox envolve tokens ERC-20 em tokens xERC-20 através de mecanismos familiares de cunhagem e queima e torna o ERC-7281 compatível com contratos de tokens ERC-20 existentes que não possuem uma interface de queima/cunhagem 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 a emissão de tokens multichain. Um token ERC-7281 implantado em várias cadeias é controlado por 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 de pontes e exploits ao impor limites dinâmicos sobre quantos tokens um determinado operador de ponte pode criar/destruir. ERC-7281 também permite que um emissor de token liste vários provedores de ponte para criar o mesmo token canônico em várias cadeias, reduzindo a dependência de um único provedor para processar operações de ponte de cadeia cruzada.

Ambos os recursos tornam o ERC-7281 uma melhoria significativa em relação às abordagens tradicionais para facilitar a ponte de cadeia cruzada dos tokens de um protocolo e têm efeitos positivos de segunda ordem para usuários, provedores de infraestrutura de interoperabilidade (especialmente agregadores) e desenvolvedores de aplicativos. Depois de discutir as especificações na próxima seção, revisaremos as vantagens e desvantagens da implementação do ERC-7281.

Uma visão geral do ERC-7281: Tokens soberanos em ponte

Queimar e cunhar tokens para os usuários

Na especificação, um projeto implanta um novo contrato de token compatível com ERC20 que implementa a interface IXERC20. Os operadores de ponte cunham tokens para usuários na cadeia de destino depois de queimar um depósito na cadeia de origem. O processo de cunhagem verifica se a quantidade de token não excede o limite da ponte e atualiza o fornecimento total do token e o limite de cunhagem da ponte se for bem-sucedido.

Para tokens ERC-20 já existentes, aplica-se uma lógica de "lockbox": o provedor de ponte envolve 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 criar 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 burn(). Esse 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 transmite a mensagem de queima para o destino. O contrato de ponte no lado de destino verifica a mensagem e cria uma quantidade igual de tokens xERC-20 para o endereço do usuário nessa cadeia. Essa criação diminui o fornecimento total de tokens e o limite de criação da ponte.

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

Um ponto importante: o contrato xERC-20 pode tecnicamente criar tokens sem a ponte verificar 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 cunhagem 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 da ponte e especificar a quantidade máxima de tokens que a ponte pode criar (mintingLimit) e queimar (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 minting.

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.

Essas funções de visualização são úteis para agregadores de pontes que precisam saber os limites disponíveis para diferentes provedores de pontes antes de encaminhar transações. Se uma ponte atinge seu limite de queima ou emissão na cadeia de origem ou destino, isso pode afetar as transações em andamento e a experiência do usuário. Portanto, os agregadores preferem encaminhar solicitações para pontes que não atingiram seus limites de emissão e queima e podem realizar a troca de uma determinada quantidade.

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 uma função de limite de taxa de token xERC-20 controlam quantos tokens uma ponte pode queimar e criar ao longo de um período predefinido). O “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 para as operações de cunhagem e queima em uma escala de tempo específica - e não um limite de taxa que controla a cunhagem e queima de acordo com os limites predefinidos durante a janela de tempo predefinida. “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 ponte). No entanto, os parâmetros de limite máximo e atual são considerações importantes para usuários e operadores de ponte. Por exemplo, o limite atual poderia afetar quanto um usuário pode com segurança conectar com um protocolo de cadeia cruzada sem enfrentar atrasos ao receber tokens xERC-20 no destino.

Cofre xERC-20

O token ERC-20 original não especifica funções para aumentar e diminuir a oferta 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 alguns anos*). Portanto, nem todo token ERC-20 tem uma função de cunhagem e queima. Como o ERC-7281 usa o mecanismo mint-and-burn favorecido pela maioria (se não todas) as bridges hoje, os tokens ERC-20 legados ou não atualizáveis não podem funcionar imediatamente com o ERC-7281.

O contrato do Sistema de Proteção de Dados fornece uma solução alternativa e permite a compatibilidade com versões anteriores com tokens existentes. Na especificação original (ou seja, um projeto implanta um novo contrato de token que implementa a interface IXERC20), os operadores de ponte só precisam chamar mint() para cunhar tokens para um usuário na cadeia de destino (depois de bloquear um depósito na cadeia de origem).

O contrato Lockbox empresta muito 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 que os operadores de ponte desbloqueiem tokens ERC-20 após a queima de tokens encapsulados 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 de sistema de proteção de dados errado. Um sistema de proteção de dados pode ser nativo ou não nativo, dependendo dos tipos de tokens aos quais ele dá suporte.

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

Cofres regulares (não nativos) custódia de tokens ERC-20 como USDC, DAI, WETH, USDT, etc. Para cunhar o USDC como um token xERC-20, por exemplo, o usuário chamaria deposit() no contrato Lockbox após bloquear o USDC.

Chamar deposit() com ETH resultaria nesses fundos sendo bloqueados para sempre, uma vez que o contrato regular do Lockbox só pode envolver e desenrolar tokens ERC-20. Chamar depositNative() com um token ERC-20 produziria resultados similares, pois os contratos nativos do Lockbox são projetados para funcionar com tokens nativos, não tokens ERC-20.

Dessa forma, ao encapsular tokens ERC-20 canônicos em tokens xERC-20 com suporte a mint/burn, 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 (criação/queima, registro correspondente, e similares), os aplicativos podem construir contratos adaptadores. Esses contratos funcionam como invólucros automatizados e desinvólucros—traduzindo efetivamente o comportamento padrão de aprovação + chamada do ERC‑20 em um esquema de criação/queima mais refinado requerido pelo xERC‑20.

Isso é necessário porque muitos protocolos de ponte (por exemplo, o CCIP da Chainlink) permanecem otimizados para o comportamento ERC-20 convencional. O contrato do adaptador pode preencher (ba-dum-tss) essa lacuna de compatibilidade consagrando essa lógica: ele deposita tokens no Lockbox para gerar a representação xERC-20 na cadeia de origem e, posteriormente, após o recebimento da mensagem na cadeia de destino, aciona o mecanismo de retirada para reverter para o ativo canônico.

Esse fluxo garante que o usuário receba um token consistente e canônico, não afetado pelos mecanismos de encapsulamento alimentados pelo xERC-20 nos bastidores. Dessa forma, os adaptadores podem permitir que os protocolos se integrem perfeitamente a pontes não compatíveis com xERC-20 e aumentem o espectro de soluções interoperáveis que eles suportam.

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

Em alto nível, o ERC-7281 tem quatro objetivos amplos:

1. Fungibilidade: Os usuários que transferem tokens da cadeia nativa do token para outra cadeia (L1/L2) devem sempre receber representações canônicas do token transferido no destino. Múltiplas versões não fungíveis do mesmo token circulando em uma cadeia não nativa são problemáticas por motivos explicados anteriormente (por exemplo, fragmentação de liquidez e baixa composabilidade do token).

A visão original de criar a especificação ERC-20 era garantir a fungibilidade e a interoperabilidade perfeita entre tokens no Ethereum em aplicações e infraestruturas do Ethereum. No entanto, após adotar um roadmap de escalonamento centrado em 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 unificados multi-rollup, restaurando a visão inicial do Ethereum.

1. Segurança: Para reduzir o risco de contraparte, os emissores de tokens devem ter a opção de selecionar entre provedores de bridge 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 os provedores de bridge parceiros – ataques isolados em um ou dois serviços de bridge não devem eliminar TVLs inteiros.

2. Bootstrapping sem liquidez para tokens de cadeia cruzada: Os DAOs de protocolo não devem ser forçados a gastar recursos (financeiros) significativos na inicialização de liquidez para tokens interligados como parte de planos de expansão de várias cadeias. Não apenas a ponte baseada em liquidez é ruim para 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 emitidos 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 proporciona para protocolos e comunidades.

Analisando os benefícios do ERC-7281

Melhorando a experiência do usuário e eliminando a fragmentação de liquidez

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

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

A dependência de caminho é um recurso de segurança valioso, mas também pode ser prejudicial para a ponte de UX e a composabilidade entre cadeias cruzadas. Por exemplo, um usuário não pode fornecer liquidez programaticamente para uma DEX entre cadeias que opera na Optimism e Arbitrum, já que o aplicativo deve aceitar opETH ou arbETH.

ERC-7281 elimina o problema ao introduzir tokens xERC-20 que permanecem fungíveis, não importa quantas vezes um usuário atravessa cadeias ou quais provedores de ponte são usados para atravessar tokens. Suponha que um usuário deseje mover USDT envolvido de Arbitrum para Optimism sem retirar primeiro para Ethereum; um provedor de ponte pode queimar tokens xERC-20 em Arbitrum e criar xERC-20s em Optimism - o valor dos tokens criados em Optimism ainda está vinculado aos tokens depositados na Lockbox e são remapeados para manter seu suporte de 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 diferentes mercados para diferentes versões do mesmo ativo.

Reforçando a soberania para 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 mantêm o controle do design e da administração de tokens interligados entre as implantações. O ERC-7281 é um híbrido entre "cunhagem de tokens canônicos por meio de uma ponte de terceiros" e "cunhagem de 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 implantam tokens cross-chain com ERC-7281 podem cunhar representações canônicas de tokens nativos por meio de várias pontes sem se deparar com o problema de versões encapsuladas não fungíveis do mesmo ativo nativo, quebrando a experiência do usuário para usuários que desejam alavancar a composição e a fungibilidade dos tokens ERC-20. Esses projetos também mantêm um nível semelhante de controle sobre implantações de cadeia cruzada de um token como um emissor de token executando 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 bloquear, cunhar e queimar tokens para usuários - são implantados e controlados pelo projeto.

Esse recurso discreto pode ser útil nos casos em que um projeto de alto perfil tem um token nativo emitido na cadeia doméstica. Usuários de outros ecossistemas desejam exposição ao token sem mantê-lo em sua cadeia nativa por diferentes motivos.

Ainda assim, o projeto não tem a capacidade ou a vontade de executar uma infraestrutura interna de ponte para cada cadeia para garantir a compatibilidade 1:1 entre os tokens interligados - nem quer desembolsar 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 interligados enquanto os votos são computados na cadeia nativa; Um provedor de ponte não alinhado com controle de tokens interligados torna-se um ponto de estrangulamento para a governança do protocolo.

Beefy, um protocolo de agricultura de rendimento, também adotou o xERC-20 por esta razão. Conforme descrito na documentação da ponte do projeto, a ERC-7281 proporcionou ao projeto mais opções para a ponte de tokens - o que se tornou necessário após um grande parceiro de ponte sofrer um hack (um tema que está rapidamente se tornando familiar para os nativos da criptografia) - e proporcionou mais controle detalhado sobre o design dos mecanismos de ponte. No caso da Beefy, o recurso de listagem permitida da ERC-7281 permitiu ao protocolo selecionar vários parceiros de ponte e oferecer aos usuários diferentes opções entre otimização de velocidade, descentralização, custos e segurança ao pontuar tokens mooBIFI.

Realinhamento de incentivos melhora a competição aberta e a segurança

A ponte baseada na liquidez frequentemente 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 experiência 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.

A ERC-7281 resolve o problema removendo a necessidade de pontes baseadas em liquidez. Sem a necessidade de criar e trocar tokens não-canônicos por tokens canônicos, pontes de qualquer tamanho podem ser aprovadas para criar o token de um projeto em um domínio remoto. Como os emissores de tokens querem minimizar a exposição a falhas de pontes, é provável que mais protocolos comecem a prestar mais atenção aos designs de segurança das pontes entre cadeias em vez de focar na liquidez primeiro.

Isso incentiva a competição aberta, pois se torna um caso de "deixe a ponte mais segura ganhar" e não "deixe a ponte mais líquida ganhar"; essa competição aberta pode tomar a forma de pontes competindo em mais recursos além de liquidez/segurança (por exemplo, taxas, APIs/SDKs, integrações de aplicativos, etc.). Estes 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; em contraste, a liquidez e os volumes de ponte são mais complexos de inicializar e requerem uma mistura de desenvolvimento de negócios, financiamento, conexões industriais, marketing e mais.

Melhor gestão de risco para emissores de tokens

O ERC-7281 introduz um limite de taxa configurável na cunhagem e queima 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 de 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 cuidadosamente os parâmetros de limitação de taxa, 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 da ponte pode levar meses para ser concluída devido à magnitude do impacto de uma terceira ponte canônica sendo hackeada; os protocolos querem garantir decisões defensáveis, onde a segurança da ponte escolhida é minuciosamente examinada para dar à comunidade garantias mais fortes de segurança. Além de ser desnecessariamente desperdiçoso de esforço e tempo, análises maratona da segurança da ponte ainda não garantem que uma ponte escolhida seja imune a exploits do dia zero.

Adotar o ERC-7281 torna a avaliação de riscos mais dinâmica. Os projetos ainda precisam concluir a diligência devida 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 não estão mais em uma posição de tudo ou nada. Em vez de passar meses analisando várias pontes para escolher uma opção, um projeto pode gastar metade do tempo escolhendo vários provedores de pontes inicialmente e definindo limites de cunhagem variados com base em uma avaliação de segurança. O emissor do token pode então conduzir revisões de segurança para determinar se aumenta ou diminui os limites de cunhagem para parceiros de pontes selecionados ou retirar os direitos de cunhagem de uma ponte (por exemplo, em resposta a um hack ou divulgação de vulnerabilidade).

O ERC-7281 também reduz a barreira para projetos que desejam optar por avanços de ponta na segurança de pontes, mas hesitam em adotar uma tecnologia específica em sua totalidade até que a tecnologia tenha sido testada em batalha e examinada rigorosamente pela comunidade (ou seja, o dilema do inovador). Suponha 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 limitados de cunhagem à 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 confiar 100% na pilha de tecnologia de uma ponte antes de atribuir direitos de cunhagem cria uma competição igual entre novos participantes e jogadores antigos - os jogadores antigos têm o incentivo para iterar em melhores abordagens de segurança, já que os emissores de tokens agora têm a flexibilidade de retirar os 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 acelerado em que falhas e problemas na segurança da 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.

Melhorando a composabilidade entre ecossistemas

Construir fluxos de trabalho de aplicativos complicados que exigem a roteamento de tokens por qualquer número de cadeias é difícil hoje devido à precificação imprevisível de pontes baseadas em liquidez. Por exemplo, um agregador de pontes que conecta Ethereum → Linea → Base tem duas opções:

1. Defina um parâmetro de tolerância de derrapagem e precifique a execução do roteamento de cadeia cruzada 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 deslizamento; em vez disso, crie lógica para obter liquidez na cadeia (por exemplo, por meio 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 em uma 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 de transmitir a transação e a transação chegar a um domínio - o que significa que o usuário não pode receber tokens canônicos no destino.

No entanto, o ERC-7281 ainda é uma melhoria nesse sentido pelos seguintes motivos:

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

As mudanças imprevisíveis na liquidez também significam imprevisibilidade na precificação das transações de ponte reprocessadas. Suponha que um agregador de ponte (ou outra aplicação) faça uma cotação para uma troca cruzada com base no preço atual de um par de tokens em um pool de liquidez de ponte (este 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 mantida e reprocessada posteriormente. Nesse caso, o desenvolvedor da aplicação não pode saber se a cotação anterior permanece precisa ou se a liquidez atingirá os mesmos níveis que 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 usuários podem ter a certeza de que as transações de cadeia cruzada não incorrerão em deslizamento, mesmo que não sejam executadas imediatamente.

Os agregadores de ponte não são os únicos a se beneficiar dessa melhoria na capacidade de composição; qualquer aplicativo de cadeia cruzada pode aproveitar a fungibilidade dos tokens xERC-20 para criar aplicativos mais interessantes. Isso é mais difícil hoje devido a problemas em torno da dependência do caminho: suponha que um desenvolvedor deseje fazer a ponte ETH do Ethereum, abrir uma posição de empréstimo em um Arbitrum DEX 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 trocar facilmente versões proprietárias - o que não é o caso, uma vez que os tokens de ponte de um projeto são fungíveis após a adoção do xERC-20.

Este fluxo de trabalho é semelhante às pontes do emissor de tokens descritas anteriormente. Vamos pegar o Circle CCTP como exemplo:

O Protocolo de Transferência Cross-Chain 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 de cadeia cruzada são processadas por meio de seu protocolo usando o esquema burn-and-mint.

No entanto, embora o CCTP seja um protocolo centralizado, como os operadores da Circle são as únicas entidades autorizadas a queimar e cunhar seus tokens USDC, o xERC-20 liquida o risco de confiança, permitindo que várias entidades com vários mecanismos de segurança operem transferências entre cadeias.

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

O ERC-7281 pode acelerar o roteiro centrado em rollup da 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, pois o Ethereum L1 não garante a segurança da ponte. Um projeto de token pode ser implementado lentamente em tal cadeia, concedendo direitos de cunhagem limitados à ponte canônica e aumentando o limite de cunhagem assim que o rollup avançar para o estágio 1.

Esse processo pode continuar até que a 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 maneira minimizada beneficia o ecossistema Ethereum, tornando mais fácil para novos L2s inicializar a liquidez e os aplicativos do token, ao mesmo tempo em que incentiva mais inovação no espaço de design de rollup.

Possíveis desvantagens da implementação do ERC-7281

Aumento de despesas gerais para equipes de gerenciamento de projetos DAO

Embora o ERC-7281 seja muito atraente para protocolos, os DAOs podem hesitar em adotar tokens xERC-20 devido à sobrecarga operacional significativa que as equipes de projeto DAO devem incorrer para gerenciar tokens xERC-20 em várias implantações.

Gerard Persoon’sGerencie tokens interligados 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 de tarefas muito longa

Uma solução proposta é para que os DAOs terceirizem algumas dessas tarefas administrativas relacionadas à gestão de tokens xERC-20 de cadeia cruzada para serviços de terceiros, mas isso é apenas trocar um compromisso (custos de recursos humanos) por outro (custos de contratação de serviços).

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

Por exemplo, um membro essencial da equipe da Lido delineou(em resposta a uma proposta para a Lido implantar wstETH como um token xERC-20 em todos os implantações) as responsabilidades atuais da equipe de PM preocupada com a infraestrutura de interoperabilidade e contrastou o conjunto com o conjunto de responsabilidades que os mesmos membros da equipe teriam que assumir se a Lido DAO votasse para ter wstETH em todos os domínios migrados para uma versão xERC-20.

Como mostra a conversa acima, o gerenciamento de tokens xERC-20 impõe um aumento não desprezível na sobrecarga administrativa para protocolos e membros da comunidade. Por exemplo, os limites da ponte exigem monitoramento ativo e avaliação da segurança da ponte para informar os ajustes nos 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 do DAO (se tais escolhas precisarem ser feitas com frequência, os membros do DAO podem sofrer fadiga do eleitor).

No entanto, isso não deve ser interpretado como um julgamento de valor sobre o ERC-7281. Cada projeto terá diferentes perfis de risco, metas de longo prazo e recursos - e esses fatores determinam coletivamente se o benefício de 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 gerenciar a sobrecarga de emissão de tokens xERC-20 e optar por um serviço gerenciado de ponte de token multichain, como o ITS (Interchain Token Service) da Axelar ou o NTT (Native Token Transfers) da Wormhole. Projetos mais estabelecidos podem ter recursos para gerenciar os custos administrativos e operacionais da emissão de um token xERC-20 e podem considerar o controle proporcionado pelo ERC-7281

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

Para projetos que não têm uma interface de cunhagem/gravação, ou não podem atualizar contratos de token para usar o IERC20 via herança, e já possuem representações canônicas de tokens nativos circulando em cadeias não nativas, migrar para tokens xERC-20 é um processo demorado que requer muita coordenação e envolve uma complexa rede de participantes - desde detentores de tokens, exchanges (DEXes e CEXes), pontes de parceiros e aplicativos integrados ao token ERC-20 legado. Mesmo com essa parte tratada, os protocolos ainda arcam com o custo de desempacotar 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 embrulhados para os usuários. O encerramento do legado ERC-20 acontece logo em seguida e envolve outro processo prolongado de compartilhamento de comunicação com a comunidade em torno do 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 governança de DAO

O gerenciamento de tokens xERC-20 em vários domínios com ERC-7281 requer governança ativa do DAO que supervisiona o protocolo. Isso envolve definir parâmetros como limites de cunhagem, atualizar o contrato do Lockbox e pausar a cunhagem ou queima de tokens. Essas decisões são sensíveis à segurança e devem ser regidas pelo DAO para evitar a responsabilidade de decisões de diretoria fechada.

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 a tokens em outras cadeias é razoável para protocolos e comunidades que buscam esse controle. No entanto, alguns protocolos podem não querer esse controle extra de DAO 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 cofre e o DAO o governar. Um invasor pode obter o controle do Lockbox e introduzir um provedor de ponte malicioso sem limites de cunhagem, tornando os tokens xERC-20 em outras cadeias inúteis.

Este cenário tem paralelos com a exploração da Multichain, onde uma vulnerabilidade na infraestrutura de assinatura de computação multiparta (MPC) permitiu que hackers comprometessem os endereços principais da Multichain que estavam custodiando tokens nativos no Ethereum e Dogecoin - esses tokens apoiavam tokens emitidos 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

ERC-7281 se encaixa no propósito quando o token é emitido por um protocolo com governança de token ou por uma entidade centralizada (por exemplo, USDC da Circle ou o CZKC stablecoin). No entanto, não é tão valioso se o protocolo for descentralizado ao máximo e não tiver governança formal - a stablecoin LUSD da Liquity é um exemplo de token que seria difícil de tornar compatível com o padrão xERC-20.

O token xERC-20 exige que uma entidade decida sobre parâmetros específicos, como limites de cunhagem e queima, e tome decisões como colocar ou não determinados provedores de bridge na lista de permissões. 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 do DAO, ao longo do tempo, isso pode causar problemas e complicar os planos de descentralização.

Risco maior de exploits que afetam os componentes principais (contrato Lockbox e provedores de ponte)

Já mencionamos como funciona a dependência de caminho e por que ela ajuda a fornecer garantias de que um exploit que afeta a cadeia A não afetará a cadeia B, ou que um exploit 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, que tem benefícios, mas também introduz uma compensação em torno da segurança:

A liquidez máxima disponível em uma 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 cunhados por diferentes provedores de pontes são fungíveis entre domínios. Os autores do ERC-7281 propõem escolher um limite de taxa para os provedores de pontes com base no valor que um emissor de tokens pode gastar para compensar perdas com cunhagem fraudulenta; mesmo assim, um limite de taxa selecionado pode ter sido muito conservador em retrospecto.

Se uma bridge com um limite alto for comprometida, os efeitos poderão ser pronunciados, mesmo para usuários de outras bridges que cunham 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 desproporcional de tokens que possa cunhar em comparação com outras pontes), mas tentar proteger o risco dessa maneira 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 regido por um DAO pode introduzir efeitos adversos de contágio no caso de um ataque de governança. Mas mesmo com governança DAO segura, um bug nos contratos Lockbox nativos/não nativos na cadeia inicial do token pode causar tantos problemas (Sifu agora é o proprietário do contrato Lockbox para um projeto e os fundos não são mais SAFU). Em comparação, esse problema é reduzido no status quo, pois os contratos de cofre (o equivalente do provedor de ponte ao contrato Lockbox) contêm apenas tokens ligados por meio do serviço de ponte correspondente. Portanto, um bug no contrato de cofre de um provedor afeta apenas os usuários que depositaram tokens nessa ponte.

Custos adicionais para integrações no ecossistema

O trabalho administrativo adicional 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 pontes precisam acompanhar as correspondências entre os tokens xERC-20 e seus contratos Lockbox correspondentes para evitar problemas como tokens de spam e ataques de spoofing. Embora um registro dessas correspondências possa ajudar, configurar tal registro é desafiador sem correr o risco de centralização ou expor os adotantes de xERC-20 a ameaças.

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

Conclusão

O ERC-7281 apresenta uma solução atraente para os problemas de tokens interligados não fungíveis e oferece recursos que aprimoram a experiência do usuário, descentralização, segurança e flexibilidade em projetos de ponte de tokens. Alguns desses problemas afetam diretamente a viabilidade do roteiro centrado em rollup, tornando o padrão xERC-20 infraestrutura crítica para o ecossistema Ethereum L2.

Vários players-chave no espaço de pontes, incluindo Hyperlane, Omni, Sygma, Protocolo do Roteador e Everclear, comprometeram-se a adotar o ERC-7281, indicando uma tração significativa para a proposta. Mesmo emissores de tokens estabelecidos (que possuem mecanismos de trabalho para pontes de tokens) — como a Circle — mostraram interesse no ERC-7281 para lidar com os desafios apresentados 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 bootstrapping sem liquidez, ao contrário das pontes consagradas, não requer infraestrutura personalizada, como pontes de emissor de token, e evita o aprisionamento do fornecedor, permitindo a cunhagem de tokens canônicos de várias pontes por provedores de ponte aprovados.

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

Isenção de responsabilidade:

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