Introdução

Os maxis modulares dizem que o futuro da criptografia são um milhão (ou mais) de domínios interconectados e usuários pulando entre blockchains como Alice passeando pelo País das Maravilhas. Por que ficar apenas em uma cadeia se você pode acessar tecnologia de ponta, aplicações inovadoras, retornos altos em staking/fornecimento de liquidez, alto desempenho e taxas de transação ultra baixas em outras blockchains?

Mas a movimentação entre blockchains é muito mais complicada do que a viagem de Alice pelo País das Maravilhas, principalmente devido às limitações inerentes às abordagens atuais de interoperabilidade de blockchain (por exemplo, pontes de cadeia cruzada). Em particular, as pontes de cadeia cruzada de hoje são inseguras ($2.5 bilhões+ perdidos em hacks de pontes), lentas, caras ou limitadas em funcionalidade - ou exibem uma combinação de propriedades da lista.

Outras questões que assolam a indústria de pontes são mais sutis, mas ainda suficientes para transformar o sonho modular maxi de um ecossistema multi-cadeia em um pesadelo para usuários e desenvolvedores - um exemplo disso é como tokens fungíveis (como ERC-20s) tornam-se não fungíveis quando atravessam diferentes cadeias através de vários protocolos de cadeia cruzada, prejudicando assim suas características como um ativo transferível. Neste artigo, exploraremos uma solução que busca preservar a fungibilidade de tokens em todas as cadeias, independentemente de onde o contrato de origem do token exista: ERC-7281: Tokens Soberanos de Ponte.

ERC-7281 estende o ERC-20 — o padrão de facto para criar tokens fungíveis na Ethereum — para permitir a cunhagem e queima de representações canônicas de tokens ERC-20 em domínios remotos por meio de múltiplas pontes aprovadas pelos emissores de tokens. Isso garante que os usuários que transferem um token ERC-20 recebam versões fungíveis do token no destino (ou seja, dois tokens podem ser trocados 1:1), mesmo quando os tokens são enviados cadeia cruzada por rotas/pontes diferentes. Importante ressaltar que os protocolos que adotam o ERC-7281 mantêm o controle dos tokens transferidos (ao contrário da situação atual em que a ponte controla um token transferido) e podem limitar as operações de cunhagem para reduzir a exposição em caso de falha da ponte.

Vamos usar o USDC como exemplo da infungibilidade entre tokens ERC-20 teoricamente idênticos em diferentes cadeias.Redes Ethereum Layer 2 (L2), como Arbitrum, Base, Optimism, é comum usar a ponte canônica para mover tokens ERC-20 populares do Ethereum L1 para essas redes. Essas versões de tokens L2 originários do L1 são comumente chamadas apenas de "tokens [inserir nome do token]".

No caso do USDC, os símbolos comuns são USDC.e, USDC.b, e assim por diante. Com o tempo, a Circle expande suas implantações de USDC para outras cadeias, incluindo L2s, onde o USDC já está ativo por meio da ponte canônica. Mesmo que esses dois tokens sejam cunhados pela mesma entidade e tenham o mesmo preço, eles são tecnicamente diferentes, tokens infungíveis, portanto não são “interoperáveis”—enquanto o USDC nativo pode ser transferido via ponte CCTP da Circle, o USDC transferido só pode ser transferido de volta para o L1 via a ponte canônica.

ERC-7281 corrige isso introduzindo uma extensão ERC-20 onde os implementadores do token podem atribuir e parametrizar diferentes fontes de ponte para ele. No exemplo acima, a Circle poderia implementar um token USDC universal em todas as L2s, onde as pontes canônicas (por exemplo, Circle Mint, Circle CCTP e outras pontes aprovadas) são todas atribuídas como capazes de cunhar os tokens de acordo com sua lógica. Para minimizar os riscos de invasões aos cunhadores, o implementador pode limitar quantos tokens cada cunhador pode cunhar e queimar no período de tempo específico - com pontes mais confiáveis, como a L2 canônica, tendo limites mais altos, e pontes com consenso centralizado tendo limites mais baixos.

Embora o ERC-7281 não seja a primeira tentativa de criar tokens de cadeia cruzada fungíveis, ele corrige problemas associados a propostas anteriores, como dependência exclusiva de fornecedor, perda de soberania para emissores de tokens, altos custos para inicializar a liquidez de tokens ponte, sobrecarga de infraestrutura e aumento da exposição a falhas de pontes.

Este relatório em duas partes examinará a justificativa para a introdução de um padrão de token com ponte soberana e fornecerá uma visão abrangente da especificação ERC-7281 (também conhecida como xERC-20). Também discutiremos os benefícios positivos e possíveis desvantagens da implementação do ERC-7281 para usuários, desenvolvedores, provedores de infraestrutura e outros atores no ecossistema Ethereum.

Um lembrete sobre pontes de blockchain

Antes de mergulhar no problema dos tokens ponte não fungíveis, é útil entender por que os tokens ponte existem em primeiro lugar. Isso, por sua vez, requer compreender a motivação e operação das pontes de blockchain - já que os operadores de ponte são os responsáveis por criar versões de tokens ponte.

Uma ponte é um mecanismo para transferir informações entre blockchains. Além de informações puramente monetárias, as pontes podem passar qualquer informação útil, como taxas de token e estado de contrato inteligente em outras cadeias. No entanto, transferir ativos (tokens) de uma cadeia para outra é o caso de uso mais comum para usuários que interagem com uma ponte hoje.

Abordagens para facilitar transferências de ativos entre cadeias variam, mas os fluxos de trabalho de ponte de tokens geralmente seguem um dos três padrões de alto nível:

Ponte de bloqueio e cunhagem

• Um usuário deseja conectar uma token de sua cadeia nativa ou "casa" (onde foi emitida inicialmente) a outra cadeia. As duas cadeias não são interoperáveis, pois cada uma implementa arquiteturas e designs de protocolo diferentes, o que impede o usuário de transferir tokens diretamente de um endereço de carteira na cadeia A para um endereço de carteira na cadeia B.
• O operador da ponte deposita tokens depositados pelo usuário na cadeia de origem em um contrato inteligente e cria uma representação “envolvida” do token nativo por meio de um contrato de token implantado na cadeia de destino.
• Quando o usuário deseja fazer a ponte na direção reversa (cadeia de destino → cadeia de origem), ele devolve os tokens envolvidos para a ponte na cadeia de destino, que verifica isso de acordo com a lógica na ponte (por exemplo, provas de conhecimento zero ou um quórum externo) e libera os tokens originais do depósito na cadeia de origem.

Queimar e criar pontes

• Em vez de bloquear tokens em custódia, esta abordagem queima (destroi) os tokens na cadeia de origem;
• A ponte então cunha uma quantidade equivalente na cadeia de destino;
• Para a viagem de retorno, os tokens ponte são queimados na cadeia de destino antes que novos tokens sejam criados na cadeia de origem;
• Isso mantém o fornecimento total de tokens enquanto permite transferências de cadeia cruzada.

trocas atômicas

• Este método troca diretamente ativos na cadeia de origem por ativos na cadeia de destino com outra parte.
• As trocas atômicas funcionam bloqueando mutuamente fundos com o mesmo valor secreto para desbloqueá-los, o que significa que se o segredo for revelado em um lado, também pode ser revelado no outro. Isso dá às trocas a propriedade de atomicidade.
• Atomicidade significa que a troca é concluída completamente (em ambos os lados) ou não é concluída, impedindo fraude ou transferências parciais/fracassadas.

A primeira abordagem (fechadura e hortelã) é atualmente a mais comum. A equivalência de valor entre um token nativo e sua correspondente representação embrulhada cunhada por uma ponte é o que permite aos usuários "transferir" ativos entre cadeias e usar um token em uma cadeia separada de onde foi inicialmente emitido.

No entanto, novos designs - como pontes baseadas em intenção - tornaram-se bastante populares. As 'intenções' permitem que os usuários expressem resultados desejados para transações ('trocar 100 USDC por 100 DAI') em vez de descrever etapas específicas para alcançar os resultados. As intenções surgiram como um desbloqueio poderoso de UX, pois simplificam muito a experiência onchain para as pessoas e tornam a criptografia mais fácil de usar, especialmente quando combinadas com cadeia cruzada.soluções de abstração de cadeia

Intenções de cadeia cruzadapermitir que os usuários transfiram tokens entre cadeias sem se preocupar com a complexidade subjacente da ponte. Em pontes baseadas em intenções, os usuários depositam fundos na cadeia de origem e especificam seu resultado desejado na cadeia de destino (sua “intenção”). Operadores especializados chamados “fillers” ou “solvers” podem cumprir essa intenção enviando os tokens solicitados ao usuário na cadeia de destino antecipadamente. Os operadores então comprovam que a transferência ocorreu para reivindicar os fundos bloqueados na cadeia de origem como reembolso.

Algumas pontes baseadas em intenções utilizam mecanismos de bloqueio e emissão por trás. Nesse caso, a ponte emite tokens envoltos que são enviados tanto para o preenchido que cumpriu a intenção do usuário - ou diretamente para o usuário se nenhum preenchido intervier. Embora as pontes baseadas em intenções adicionem uma camada extra de eficiência por meio de sua rede de solucionadores, elas ainda dependem fundamentalmente dos mesmos princípios que as pontes tradicionais de bloqueio e emissão.

Podemos pensar em cada token envolvido, quer tenha sido criado através de pontes tradicionais ou baseadas em intenções, como um IOU do operador da ponte prometendo liberar uma quantidade do token subjacente do contrato de garantia. O valor desses ativos envolvidos correlaciona-se diretamente com a capacidade (percebida) do operador da ponte de processar solicitações dos detentores para retirar tokens nativos mantidos em garantia na cadeia de origem do token.

A ponte autorizada a bloquear os tokens subjacentes na cadeia de origem e cunhar suas representações envolventes na cadeia de destino garante que o fornecimento total de tokens permaneça constante. Para uma unidade do token subjacente, exatamente uma unidade do token envolvente correspondente é cunhada, e vice-versa. Se uma aplicação aceita um token envolvente como meio de troca ou usa ativos envolventes como moeda, os desenvolvedores e usuários da aplicação confiam no provedor da ponte para garantir os ativos "reais" que respaldam o token envolvente.

Por que precisamos de pontes?

A capacidade de transacionar com uma versão sintética de um ativo em uma cadeia remota - possibilitada por pontes que criam representações do ativo - é uma função poderosa e permite que desenvolvedores e usuários aproveitem os benefícios da interoperabilidade de cadeias cruzadas. Alguns desses benefícios incluem acesso a mais liquidez, exposição a novos usuários e flexibilidade para usuários (que podem interagir com aplicativos favoritos de diferentes cadeias sem fricção).

Para entender melhor como isso funciona na prática e por que isso é importante tanto para os desenvolvedores quanto para os usuários, vamos examinar um exemplo concreto usando uma troca descentralizada fictícia chamada BobDEX. Este exemplo demonstrará como tokens envoltos permitem a expansão de cadeia cruzada, destacando tanto os benefícios quanto as complicações potenciais que podem surgir:

BobDEX é uma bolsa de troca automatizada (AMM) que Bob criou no Ethereum para permitir trocas sem confiança entre diferentes ativos. BobDEX tem um token nativo, $BOB, que também funciona como um token de governança e um token de recompensa para provedores de liquidez (LPs). Neste último caso, BobDEX emite tokens BOB para provedores de liquidez (LPs), concedendo aos usuários que fornecem liquidez a uma taxa de juros sobre as taxas pagas pelos usuários do DEX que trocam ativos depositados na pool.

A participação de mercado do BobDEX cresceu significativamente, mas as limitações do Ethereum L1 impedem um crescimento maior. Por exemplo, alguns usuários não querem usar o BobDEX no Ethereum devido às altas taxas de gás e atrasos nas transações; da mesma forma, outros usuários desejam exposição ao preço dos tokens $BOB sem precisar possuir os tokens nativos $BOB no Ethereum.

Para resolver o problema, Bob implanta uma versão do BobDEX na Arbitrum (uma rollup de camada 2 (L2) com baixa taxa e alta taxa de transferência) e implanta uma versão envelopada do token BOB (wBOB) na L2 por meio da ponte Arbitrum-Ethereum. BobDEX na Arbitrum é idêntico ao BobDEX no Ethereum, exceto que usa wBOB - e não tokens BOB nativos - para recompensas de LP e governança.

A diferença nos tokens de aplicação (BOB envolvido vs. BOB nativo) não faz diferença do ponto de vista dos usuários (por exemplo, provedores de liquidez) que interagem com o BobDEX no Arbitrum. Uma vez que os tokens wBOB são garantidos por tokens BOB reais mantidos na ponte Arbitrum-Ethereum, os detentores de tokens wBOB podem facilmente trocar por tokens nativos BOB ERC-20 no Ethereum, interagindo com o contrato de ponte.

A situação é vantajosa tanto para Bob quanto para os usuários:

1. Bob pode atrair mais usuários, especialmente usuários que desejam taxas de gás baixas e confirmações de transação rápidas ao negociar na BobDEX
2. Os LPs podem ganhar recompensas ao fornecer liquidez ao BobDEX sem lidar com os altos custos de gás do Ethereum e os longos tempos de confirmação
3. Os Hodlers podem comprar tokens wBOB no mercado para lucrar com as mudanças no preço dos tokens BOB sem interagir com o contrato BOB ERC-20 na Ethereum

Os benefícios da ponte também se estendem à melhoria da inovação componível e desbloqueio de novos casos de uso que alavancam a liquidez de um token bridged. Por exemplo, Alice pode criar um protocolo de empréstimo chamado AliceLend no Arbitrum que aceita wBOB como garantia de mutuários para expandir a utilidade de wBOB e criar um novo mercado para empréstimo e empréstimo.

Os credores que fornecem liquidez ao AliceLend têm a certeza de receber depósitos: se um usuário não cumprir um empréstimo, o AliceLend leiloa automaticamente tokens wBOB depositados como garantia para reembolsar os credores. Neste caso, os compradores da garantia wBOB liquidada assumem o papel de LPs no BobDEX e têm a mesma garantia de que os tokens wBOB podem ser trocados 1:1 por tokens BOB originais.

A ponte de cadeia cruzada em sua forma atual forneceu uma solução viável para garantir interoperabilidade entre Ethereum L2s (anteriormente isolados em silos)e facilitando novas aplicações (por exemplo, empréstimos de cadeia cruzada e DEXes de cadeia cruzada). Mas o ecossistema de pontes está atualmente lidando com limitações que impedem um maior crescimento, como a não fungibilidade de tokens de cadeia cruzada—vamos explorar esse problema em detalhes posteriormente.

Por que os tokens ponte se tornam não fungíveis?

O fluxo de trabalho de travamento e criação de moedas descrito anteriormente parece simples no papel, mas, na realidade, requer muito esforço de engenharia e design de mecanismos para funcionar corretamente.

O primeiro desafio é garantir que as versões embrulhadas de um token conectado estejam sempre respaldadas por tokens nativos bloqueados na cadeia de origem. Se um invasor criar representações de um token em uma cadeia remota sem depositar tokens nativos na cadeia de origem, pode tornar a ponte insolvente trocando (tokens embrulhados fraudulentamente cunhados) por tokens nativos na cadeia de origem e impedindo que usuários legítimos - que depositaram no contrato da ponte antes de cunhar tokens embrulhados - retirem os depósitos.

O segundo desafio é mais sutil e deriva da natureza das tokens em ponte: duas representações de uma token emitida por provedores de ponte na mesma cadeia remota não podem ser trocadas 1:1 por outra. Podemos usar outro exemplo de dois usuários tentando trocar tokens em ponte por meio de rotas diferentes para ilustrar esse aspecto do problema associado à movimentação de tokens entre cadeias:

• Alice faz a ponte de USDC do Ethereum para Arbitrum através da ponte Arbitrum canônica e recebe 200 USDC.e em Arbitrum, enquanto Bob faz a ponte de USDC para Arbitrum através da Axelar e recebe 200 axlUSDC em Arbitrum. Alice e Bob fazem um acordo para Alice enviar 200 USDC para Bob (em troca de 200 USDT) para que Bob possa sacar 400 USDC para o Ethereum.
• Bob tenta retirar 400 USDC via axlUSDC e recebe apenas 200 USDC, juntamente com uma mensagem explicando que a ponte só tem 200 USDC para dar a Bob. Bob está confuso, já que os tokens ERC-20 envolvidos devem ser 'fungíveis' e não devem apresentar disparidades que impeçam qualquer pessoa de trocar tokens ERC-20 1:1 em qualquer aplicativo.
• Bob aprende uma lição difícil sobre a ponte de cadeia cruzada: "token ERC-20 fungível" nem sempre significa "você pode trocar este token 1:1 com outros tokens ERC-20 em diferentes aplicações". A tentativa de Bob de fazer negócios arriscados com Alice - arriscados porque Alice pode não devolver os tokens - dá espetacularmente errado.

Bob após ser enganado em uma troca

Por que Bob não pode sacar 400 USDC se ele e Alice receberam versões envelopadas do mesmo ativo subjacente na cadeia de destino? Você deve se lembrar que mencionamos que tokens emitidos em diferentes cadeias são incompatíveis, então a representação de um token nativo emitido em uma cadeia não nativa é um IOU da ponte prometendo pagar uma quantidade dos tokens nativos de volta (dependendo de quanto resta) quando o usuário deseja voltar a usar a cadeia nativa do token.

O valor de cada token transferido está assim ligado ao provedor da ponte responsável por manter os depósitos na cadeia de origem e cunhar representações na cadeia de destino; o provedor da ponte do Bob só pode pagar ao Bob 200 USDC, pois é a quantia que tem fundos para cobrir a partir do seu depósito; os 200 USDC da Alice não podem ser retirados através do provedor da ponte do Bob, pois nunca recebeu o depósito ou emitiu um IOU para a Alice. Alice deve retirar seus USDC bloqueados do Arbitrum no Ethereum e passar pela ponte do Bob antes de Bob poder acessar os tokens restantes.

O dilema de Bob e Alice aponta para um problema na interligação entre domínios onde várias representações não fungíveis de um ativo subjacente são criadas por provedores de ponte concorrentes. O outro problema com diferentes representações ERC-20 do mesmo ativo é que eles não podem ser negociados em um único pool de liquidez.

Usando o exemplo anterior, se tivermos axlUSDC e USDC.e na cadeia e quisermos trocá-los por ETH e vice-versa, devemos implantar dois pools de liquidez: ETH/axlUSDC e ETH/USDC.e. Isso leva a um problema chamado de "fragmentação de liquidez" – uma situação em que os pools de negociação têm liquidez menor do que poderiam ter de outra forma, porque há vários pools que se adequam essencialmente ao mesmo par de negociação.

A solução é ter uma única versão 'canônica' de um token circulando na cadeia de destino para que Bob e Alice possam trocar tokens sem que cada pessoa precise sacar da ponte na cadeia de origem. Ter um token canônico por cadeia também beneficia os desenvolvedores, pois os usuários podem se mover rapidamente entre ecossistemas sem lidar com problemas de liquidez do token.

Então, como implementamos versões canônicas de um token em cada cadeia na qual se espera que seja usado e transferido entre elas? A próxima seção explica algumas das abordagens populares para criar tokens canônicos em múltiplas cadeias.

Implementando tokens canônicos em diferentes cadeias

Criar um token canônico por cadeia não é simples e existem várias opções com diferentes compensações e vantagens. Ao criar um token canônico por cadeia, geralmente precisamos pensar em quem confiar sobre a existência de IOUs que respaldam o valor de um token específico. Suponha que você seja o criador de um token e deseje que ele seja utilizável e transferível em diferentes cadeias sem enfrentar problemas de fungibilidade; você tem quatro opções:

1. Cunhar tokens canônicos via pontes de rollup/sidechain canônicas de cadeia cruzada
2. Mint tokens canônicos através de um provedor de ponte de terceiros
3. Mintar tokens canônicos através de uma ponte de emissão de tokens
4. Emissão direta de várias cadeias com trocas atômicas

As três primeiras opções dependem de vários mecanismos de ponte para facilitar o movimento de tokens entre cadeias. No entanto, como criador de token, você também pode optar por contornar completamente as pontes emitindo o token nativamente em cada cadeia suportada. Sob essa abordagem, em vez de depender de tokens embrulhados ou infraestrutura de ponte, você mantém implantações separadas, mas coordenadas de tokens em várias cadeias, com trocas atômicas possibilitando a troca sem confiança entre cadeias.

Essa abordagem requer uma infraestrutura sofisticada para manter a liquidez entre cadeias e facilitar as trocas atômicas. No entanto, a complexidade de gerenciar várias implantações nativas historicamente limitou essa abordagem a protocolos maiores com recursos técnicos substanciais.

1. Tokens canônicos da Casa da Moeda através de pontes canônicas rollup/sidechain

Se uma cadeia tem uma ponte canônica (consagrada), você pode atribuir o direito de cunhar representações do token do seu protocolo para usuários que desejam fazer a ponte a partir da cadeia nativa. Transações encaminhadas através da ponte canônica da cadeia (depósitos e retiradas) geralmente são validadas pelo conjunto de validadores da cadeia, o que fornece garantias mais fortes de que os depósitos na cadeia original respaldam de forma crível todas as representações cunhadas.

Embora a ponte canônica esteja cunhando a representação canônica de um token, outras representações ainda existirão. Isso acontece simplesmente porque as pontes canônicas geralmente têm limitações que as impedem de oferecer aos usuários a melhor experiência. Por exemplo, fazer a ponte do Arbitrum/Optimism para o Ethereum por meio da ponte canônica do rollup incorre em um atraso de sete dias, pois as transações devem ser validadas por verificadores – e possivelmente contestadas por um prova de fraudeAntes da camada de liquidação do rollup (Ethereum) finalizar um lote de transações, se inválido.

Usuários de Rollup que desejam saídas mais rápidas devem usar outros provedores de ponte que possam assumir a propriedade das saídas de Rollup pendentes e fornecer liquidez antecipada na cadeia de destino desejada do usuário. Quando essas pontes usam o modelo tradicional de bloqueio e emissão, acabamos com múltiplas representações envolvidas de um token emitido por diferentes protocolos e enfrentamos os mesmos problemas descritos anteriormente.

Sidechains com conjuntos de validadores independentes têm menor latência à medida que os saques são executados quando o protocolo de consenso da sidechain confirma um bloco contendo uma transação de retirada. A ponte Polygon PoS é um exemplo de uma ponte canônica conectando uma sidechain a diferentes domínios (incluindo rollups Ethereum e mainnet Ethereum).

Observação: Referimo-nos à cadeia original de PoS da Polygon, não acadeia validium planejadaque usará o Ethereum para liquidação. Polygon se tornará um L2 assim que a transição de uma sidechain garantida por validadores externos para um validium garantido pelo consenso do Ethereum estiver completa.

No entanto, as pontes de sidechain também compartilham uma fraqueza com as pontes canônicas de rollup: os usuários só podem fazer a ponte entre um par de cadeias conectadas. Eles não podem fazer a ponte para outras blockchains usando a ponte canônica. Por exemplo, você não pode fazer a ponte de Arbitrum para Optimism hoje usando a Arbitrum Bridge ou fazer a ponte de Polygon para Avalanche via Polygon PoS bridge.

1.1. Criar tokens canônicos usando pontes de liquidez

Depender de uma ponte nativa de rollup para mover tokens canônicos vem com vários problemas, como baixa liquidez e atrasos na movimentação de ativos. Os protocolos contornam esse problema trabalhando com pontes de liquidez para facilitar saques rápidos e pontes de baixa latência*.

Sob este acordo, pontes de liquidez aprovadas (a) criam representações embrulhadas do token de um protocolo na cadeia de origem (b) trocam tokens embrulhados pela representação canônica no destino por meio de um pool de liquidez de propriedade do protocolo.

A representação canônica do token na cadeia de destino geralmente é a versão cunhada pela ponte canônica da sidechain/rollup, embora exceções existam (como veremos mais tarde). Por exemplo, a versão canônica do USDT na Optimism é a opUSDT cunhada pela Optimism Bridge.

Cada ponte de liquidez funciona como uma DEX com um Automated Market Maker (AMM) para executar trocas entre pares de ativos depositados em diferentes pools de liquidez. Para incentivar a provisão de liquidez, as pools de AMM compartilham uma parte das taxas de troca com os detentores que travam tokens canônicos nos contratos da pool.

Isso é semelhante ao modelo da Uniswap; a única diferença perceptível é que os pares de ativos geralmente são a representação da ponte de liquidez de um token em relação à representação canônica. Por exemplo, um usuário que faz uma ponte de USDT para Optimism através do Hop terá que trocar hUSDT em Optimism através da piscina huSDT:opUSDT.

O fluxo de trabalho para a ponte através de uma ponte de liquidez será assim:

• Bloquear tokens nativos na cadeia de origem
• Representação da ponte Mint do token nativo na cadeia de destino
• Troque a representação em ponte pela representação canônica na cadeia de destino por meio do pool AMM
• Enviar tokens canônicos para o usuário

Esse processo é semelhante para todas as pontes de liquidez (Across, Celer, Hop, Stargate, etc.). No entanto, geralmente é abstraído do usuário final - especialmente pelos solvers/fillers - e parecerá uma única transação, apesar de envolver muitas partes móveis.

Ao fazer a ponte de volta para a cadeia de origem, o usuário queima a representação canônica ou troca o token canônico pela representação da ponte via AMM antes de queimar essa representação e fornecer o recibo de queima. Uma vez confirmado, o usuário pode retirar os tokens nativos bloqueados no início. (Assim como na operação anterior, os detalhes sujos de mover os tokens de volta para a cadeia original são ocultados do usuário e gerenciados pelos solvers).

A ponte de liquidez é excelente, principalmente porque resolve o problema de latência na ponte rollup; por exemplo, a Hop permite que partes especializadas conhecidas como "Bonders" atestem a validade da transação de saque de um usuário na L2 e antecipem o custo de saque da ponte L1 do rollup. Cada Bonder executa um nó completo para a cadeia L2 e pode determinar se a transação de saída de um usuário eventualmente será confirmada na L1, reduzindo o risco de um usuário iniciar uma retirada fraudulenta e causar perdas para o Bonder.

As pontes de liquidez também permitem que os usuários se movam entre mais cadeias, ao contrário das pontes canônicas; por exemplo, Hop permite que os usuários façam a ponte entre Arbitrum e Optimism sem precisar sacar para o Ethereum primeiro. Assim como a ponte rápida L2→L1, a ponte rápida L2→L2 requer que os Bonders executem um nó completo para a cadeia de origem L2 confirmar as retiradas antes de antecipar o custo de cunhar tokens para um usuário na cadeia de destino L2. Isso possibilita mais compossibilidade entre rollups e melhora drasticamente a experiência do usuário, pois os usuários podem mover tokens entre rollups sem problemas.

Mas a ponte de liquidez também tem desvantagens que afetam a utilidade de usar a ponte consagrada de uma cadeia para criar a representação canônica de um token em uma cadeia L2/L1.

Desvantagens das pontes de liquidez

1. Deslizamento

O deslizamento é uma diferença na quantidade de tokens esperados e recebidos ao interagir com um AMM. O deslizamento ocorre devido aos swaps de preços do AMM de acordo com a liquidez atual em um pool - o preço é tal que o equilíbrio é mantido entre o saldo de cada ativo em um par após a conclusão de um swap, o que pode mudar entre o momento em que um usuário inicia uma negociação e a execução da troca.

Baixa liquidez para ativos cruzados também pode aumentar o deslizamento; se a piscina não tiver liquidez suficiente para reequilibrar um lado da piscina, uma grande negociação pode deslocar o preço por uma grande margem e resultar em usuários executando trocas a preços mais altos. Espera-se que os arbitrageurs ajudem a corrigir as disparidades entre as piscinas que negociam o mesmo ativo, mas podem ser desencorajados de negociações de arbitragem envolvendo tokens com baixa atividade / valor de negociação.

Isso também afeta os desenvolvedores que constroem aplicações de cadeia cruzada, pois eles devem levar em conta casos excepcionais em que ocorre escorregamento; o usuário não pode concluir uma operação de cadeia cruzada devido a receber quantidades menores de um token em uma ou mais cadeias de destino.

Aplicativos como agregadores de pontes (que não podem saber se uma ponte de liquidez terá liquidez suficiente para cobrir uma troca na cadeia de destino sem derrapagem) contornam o problema especificando uma tolerância máxima de derrapagem e usando isso para informar as cotações fornecidas aos usuários. Embora isso evite reversões de transações, os usuários sempre perdem um percentual do token da ponte, independentemente da liquidez nas pools de AMM de uma ponte.

2. Restrições de Liquidez

Um desafio fundamental com pontes de liquidez é a exigência absoluta de liquidez suficiente na cadeia de destino. Ao contrário das pontes tradicionais de bloqueio e cunhagem, onde a cunhagem de tokens é apoiada diretamente por ativos bloqueados, as pontes de liquidez dependem dos tokens disponíveis nas pools AMM para completar transferências entre cadeias. Quando a liquidez cai abaixo de limites críticos, todo o mecanismo de ponteamento pode efetivamente deixar de funcionar.

• As operações da ponte podem parar completamente se a liquidez cair muito baixa, impedindo que os usuários concluam suas transferências pretendidas;
• Os usuários podem ser obrigados a dividir transferências grandes em transações menores para evitar a exaustão da liquidez da pool;
• Durante períodos de alta volatilidade ou estresse de mercado, os provedores de liquidez podem se retirar das pools, precisamente quando a funcionalidade de ponte é mais necessária;
• A inicialização de novos pares de tokens torna-se particularmente desafiadora, pois é necessária uma liquidez inicial significativa para tornar a ponte operacional.

A exigência de liquidez cria uma dependência circular: as pontes precisam de liquidez substancial para funcionar de forma confiável, mas atrair provedores de liquidez requer demonstrar uso consistente da ponte e geração de taxas. Esse problema de ovo e galinha é particularmente agudo para tokens novos ou negociados com menos frequência, que podem ter dificuldade em manter liquidez suficiente em várias cadeias.

3. Incentivos desalinhados

Uma ponte de liquidez é útil na medida em que pode cobrir swaps da representação ponteada para o token canônico na cadeia de destino sem que os usuários incorram em deslizamentos excessivos; os custos de gás de interação com a ponte também determinam o valor de uma ponte de liquidez do ponto de vista do usuário. Assim, agregadores de pontes e equipes de projetos, emitindo um token, priorizam pontes com base na quantidade de liquidez e custos de transação.

Embora isso garanta que os usuários que fazem a ponte entre os tokens de um projeto ou usam um agregador de pontes para enviar tokens de cadeia cruzada tenham uma melhor UX, selecionar pontes com base na liquidez coloca pontes incapazes de gastar em incentivos de provedor de liquidez (LP) em desvantagem. Além disso, selecionar pontes com base em taxas de transação puras enviesa a competição a favor de pontes que adotam uma abordagem centralizada para reduzir os custos operacionais e podem cobrar taxas mais baixas em transações de ponte. Em ambos os casos, as pontes não estão competindo no que é talvez a métrica mais importante: segurança.

As pontes baseadas em liquidez também desfavorecem ativos de cauda longa com menor atividade de negociação (o que os torna menos propensos a atrair LPs). Emitentes de tokens de cauda longa (ou novos tokens com baixos volumes de pontes) terão que configurar pools AMM e inicializar a liquidez para cobrir trocas de tokens nativos (pontes via uma ponte de liquidez) contra a representação canônica do token do emissor ou trabalhar com operadores de pontes para aumentar os incentivos financeiros para LPs fornecerem liquidez para esse ativo.

4. Má experiência de ponte

As pontes de liquidez são uma melhoria nas pontes canônicas, mas não estão livres de problemas de UX também. Além de sofrerem deslizamento em trocas entre cadeias cruzadas, os usuários podem ser incapazes de completar uma transação de ponte imediatamente na cadeia de destino porque a ponte não tem liquidez suficiente para cobrir a negociação com o token canônico na cadeia de destino. As pontes não podem saber quanto de liquidez para um par de ativos existirá até que a mensagem de um usuário para trocar tokens alcance a cadeia de destino, então este caso é em sua maioria inevitável.

Os usuários têm duas opções nessa situação (ambas não ideais):

• Aguarde até que a ponte tenha liquidez suficiente para concluir a troca e retirar os tokens canônicos. Isso é subótimo devido ao atraso suportado em transações de ponte e porque um usuário não pode saber se receberá a mesma quantidade de tokens citados inicialmente, já que a liquidez do pool pode mudar arbitrariamente em períodos muito curtos.
• Receba a representação do token proprietário da ponte (por exemplo, hUSDT para Hop Bridge). Isso é subótimo, pois a maioria das aplicações preferirá se integrar à representação canônica de um token nativo (por exemplo, opUSDT cunhado pela Optimism Bridge) e pode não aceitar o ativo envolvido do usuário.

2. Criar tokens canônicos via uma ponte canônica de terceiros

Um dapp de várias cadeias pode contornar o problema de tokens não fungíveis interligados selecionando uma única ponte para criar representações canônicas do token do dapp em cada cadeia onde o dapp está implantado. Assim como pontes canônicas criando representações aprovadas do token de um projeto, essa abordagem requer o mapeamento de tokens criados em cadeias remotas para o contrato de token implantado na cadeia principal do projeto - garantindo que o fornecimento de tokens permaneça o mesmo globalmente. O provedor da ponte deve rastrear a criação e queima de um token e garantir que as operações de criação e queima estejam sincronizadas com o fornecimento de tokens na cadeia principal.

O uso de um único provedor de ponte oferece mais flexibilidade para as equipes de projeto, especialmente porque as pontes de terceiros são incentivadas a suportar a ponte entre uma gama mais ampla de ecossistemas em comparação com pontes canônicas que se conectam apenas a, no máximo, uma cadeia. Se existir uma ponte em todas as cadeias onde um aplicativo é implantado, os usuários podem mover rapidamente a cadeia cruzada sem precisar se retirar de volta para a cadeia doméstica; um provedor de ponte só precisa garantir que os tokens cunhados na cadeia de destino A sejam queimados antes que um usuário ceda tokens na cadeia de destino B e os tokens canônicos on-chain B sejam (re)mapeados para o token na cadeia inicial.

O problema dos tokens pontuais não fungíveis também é eliminado; desde que os usuários utilizem a provedora de ponte aprovada, eles sempre podem trocá-los 1:1 com outros tokens pontuais. Essa abordagem ainda corrige os problemas de pontes baseadas em liquidez no modelo de ponte canônica:

• Os usuários não sofrem deslizamento nas transações de bridge, pois o provedor de bridge não precisa converter sua representação em relação a uma representação canônica por meio de um AMM - o token do provedor de bridge é a representação canônica do token bridged em todos os domínios. O valor dessas representações está vinculado ao valor dos tokens bloqueados pelo provedor de bridge na cadeia nativa do token.
• Os usuários sofrem pouco ou nenhum atraso na ponte, pois o provedor da ponte pode criar representações encapsuladas na cadeia de destino imediatamente após a chegada da mensagem mint() no destino.
• Os desenvolvedores podem terceirizar a gestão de implantações de tokens multi-chain para operadores de ponte sem se preocupar com a inicialização da liquidez AMM ou programas de incentivo à provisão de liquidez.

Alguns exemplos de tokens fornecidos por única ponte no mundo incluem o Token Fungível Omnichain (OFT) da LayerZero, o Serviço de Token Interchain (ITS) da Axelar, o xAsset do Celer e o anyAsset da Multichain. Todos os exemplos são essencialmente tokens proprietários e são incompatíveis com as representações do mesmo token enviadas por meio de um provedor de ponte diferente. Este detalhe sutil destaca alguns problemas com essa abordagem para lidar com tokens em pontes. Nomeadamente os seguintes:

• Vendor lock-in
• Perda de soberania
• Alta exposição a falhas de ponte
• Perda das funcionalidades personalizadas do token nas cadeias de destino
• Sendo limitado às cadeias suportadas pelo fornecedor
• Incapacidade de manter o mesmo endereço de token em todas as cadeias desejadas, o que pode prejudicar a segurança do usuário ou deixá-los vulneráveis a phishing

Desvantagens de usar pontes canônicas de terceiros

1. Fidelização de fornecedor

Selecionar um único provedor de ponte para criar representações canônicas em uma ou mais cadeias expõe os desenvolvedores ao risco de bloqueio do fornecedor. Como cada provedor de ponte cria uma representação proprietária compatível apenas com sua infraestrutura (e projetos integrados do ecossistema), o modelo de provedor único de ponte bloqueia efetivamente um emissor de token a um serviço de ponte específico sem a opção de mudar para outra ponte no futuro.

É possível trocar de provedores de ponte, mas os custos de troca são altos o suficiente para desencorajar a maioria dos projetos a seguir por esse caminho. Para dar uma ideia aproximada, suponha que um desenvolvedor (a quem chamaremos de Bob) emitiu um token (BobToken) no Ethereum e escolhe a LayerZero OFT para criar versões canônicas do BobToken no Optimism, Arbitrum e Base. BobToken tem um fornecimento fixo de 1.000.000 tokens, e os tokens bridged minted via LayerZero representam 50% do fornecimento total de BobTokens em circulação.

O arranjo comercial avança sem problemas até que Bob decida que os usuários estão melhores fazendo a ponte de BobTokens por meio de um serviço de ponte concorrente (por exemplo, Axelar). No entanto, Bob não pode simplesmente dizer: "Estou mudando para a ITS da Axelar para criar representações canônicas do BobToken no Optimism, Base e Arbitrum"; já que os tokens OFT e ITS são incompatíveis, Bob corre o risco de criar problemas tanto para os usuários antigos quanto para os novos, pois dois BobTokens potencialmente não são fungíveis (reintroduzindo o problema que descrevemos anteriormente). Além disso, aplicativos integrados à versão do BobToken da LayerZero não podem aceitar a versão do BobToken da Axelar como substituto - o que fragmenta a liquidez do BobToken em várias cadeias onde representações concorrentes do BobToken coexistem.

Para tornar a transição possível, Bob precisa convencer os usuários a desembrulhar as representações embrulhadas de BobToken criadas através da LayerZero, enviando uma transação que queima tokens OFT em pontes e desbloqueia BobTokens na Ethereum. Os usuários agora podem alternar para a nova representação canônica de BobToken bloqueando tokens com Axelar na Ethereum e recebendo BobTokens canônicos (mapeados para o fornecimento do contrato de token na Ethereum) na cadeia de destino. Isso é tanto custoso quanto gera grandes coordenadas e sobrecarga operacional para as equipes de gerenciamento de projetos DAO, então aderir ao provedor escolhido geralmente é a opção mais segura.

No entanto, isso deixa desenvolvedores como Bob em uma posição problemática, pois a dependência do fornecedor torna impossível a troca se um provedor de ponte deixar de cumprir os termos do contrato, tiver um conjunto limitado de recursos, carecer de integrações de ecossistema expansivas, oferecer uma experiência do usuário ruim, etc. Além disso, fornece pontes com alavancagem quase infinita: o provedor de ponte pode fazer coisas arbitrárias como limitar a taxa de usuários que fazem a ponte de BobTokens sem motivos claros, aumentar as taxas de ponte, ou até mesmo censurar operações de ponte. As mãos de Bob estão atadas neste caso, pois romper de forma limpa com uma ponte de terceiros canônica com defeito é tão complexo quanto manter a relação comercial.

2. Perda de soberania para protocolos

A parte conclusiva da seção anterior sobre o aprisionamento de fornecedores destaca outro problema ao usar uma ponte de terceiros canônica: os emissores de tokens abrem mão do controle dos tokens canônicos em troca de maior conveniência e melhorias na experiência do usuário. Para usar o exemplo anterior: BobToken no Ethereum está totalmente sob o controle de Bob, pois ele controla o contrato de token ERC-20 subjacente, mas BobToken no Optimism, Arbitrum e Base são controlados pela LayerZero, que possui o contrato OFT que emite representações canônicas de BobToken nessas blockchains.

Embora Bob possa esperar que a LayerZero alinhe as representações canônicas com o design original do token nativo, isso nem sempre pode ser o caso. Nos piores cenários, o comportamento do BobToken no Ethereum pode divergir significativamente do comportamento do BobToken na Optimism porque o provedor de ponte implementa uma versão radicalmente diferente do contrato do token, criando problemas para os usuários do protocolo. Esse problema também pode ser exacerbado pela dinâmica principal-agente, onde os objetivos e interesses de um protocolo e do provedor de ponte divergem.

3. Alta exposição a falhas de ponte

Na primeira abordagem, onde os tokens são interligados em cadeia cruzada através da ponte canônica de cada cadeia, o risco para o emissor do token de uma exploração que afeta uma ponte é contido nessa ponte. Por exemplo, suponha que um hacker consiga comprometer uma ponte de liquidez e criar quantidades infinitas de um token envolvido sem depositar garantia. Nesse caso, ele só pode sacar até a liquidez máxima disponível para o ativo envolvido em pools de liquidez (por exemplo, criar cUSDT na Optimism → trocar cUSDT por opUSDT canônico → sacar opUSDT para Ethereum via ponte rápida → trocar por USDT nativo em Ethereum).

No modelo de ponte canônica de terceiros, o risco para um emissor de token de um ataque que afeta a ponte parceira é equivalente à quantidade total de tokens que um invasor cunha em cadeias remotas onde a ponte afetada tem uma implantação. Isso é possível porque cada representação canônica em todas as cadeias pode ser trocada 1:1 por tokens canônicos emitidos em outras cadeias:

Suponha que um atacante comprometa uma ponte de terceiros na cadeia B e emita 1000 tokens (onde o token é emitido inicialmente na cadeia A) sem depositar garantia. Os tokens do atacante na cadeia B não são mapeados para o contrato da cadeia inicial, portanto, ele não pode sacar da cadeia A. Ainda assim, ele pode atravessar para a cadeia C e trocar 1000 tokens da cadeia B por 1000 tokens da cadeia C - lembre-se, cada token de cadeia cruzada é compatível e fungível, pois eles originam do mesmo serviço de ponte. Os tokens da cadeia C são mapeados para o contrato da cadeia inicial, pois foram emitidos legitimamente por usuários que bloquearam tokens na cadeia A (a cadeia inicial do token), permitindo que o atacante queime tokens na cadeia C e retire tokens nativos na cadeia A e potencialmente complete o itinerário trocando os tokens por um offramp de CEX ou fiat.

(Fonte)

Perda de recursos de token personalizado

Ao usar uma ponte de terceiros canônica, os emissores de tokens frequentemente perdem a capacidade de implementar recursos personalizados ou comportamentos de token que existem em sua implantação original. Isso acontece porque os provedores de pontes tendem a usar contratos de implementação ERC-20 padronizados que podem não suportar funcionalidades especializadas presentes na implementação original do token.

Recursos comuns de token, como delegação de voto (ZK), mecanismos de rebase (stETH, USDM), capacidades de taxa de transferência (memecoins), funções de inclusão e exclusão de lista (USDT, USDC), transferências pausáveis ​​e regras ou permissões de emissão especiais são frequentemente removidos quando os tokens são conectados através de um provedor terceirizado, pois a versão conectada geralmente usa uma implementação básica de ERC-20. Essa perda de funcionalidade cria inconsistências na forma como o token opera em diferentes cadeias e pode potencialmente quebrar integrações que dependem desses recursos personalizados.

A padronização de tokens em pontes, embora mais simples do ponto de vista do provedor de ponte, reduz efetivamente as capacidades do token e pode prejudicar a capacidade do emissor de manter um comportamento de token consistente em todo o ecossistema multi-cadeia de sua aplicação. Essas questões podem tornar as expansões de cadeia cruzada um pesadelo para os desenvolvedores e representar um obstáculo para a realização do sonho de aplicativos vivendo em várias cadeias.

Cadeias com suporte limitado

Os emissores de tokens tornam-se dependentes da cobertura de rede e dos planos de expansão do provedor de ponte escolhido. Se o provedor de ponte não suportar uma determinada rede blockchain para a qual o emissor do token deseja expandir, eles enfrentam duas escolhas subótimas:

• Aguarde o provedor da ponte adicionar suporte para a cadeia desejada, o que pode levar muito tempo ou nunca acontecer devido aos altos custos de integração (por exemplo, a inequivalência EVM da Era ZKsync que fez com que muitos dapps nunca fossem implantados nele)
• Use um provedor de ponte diferente para essa cadeia específica, o que reintroduz o problema de tokens não fungíveis e fragmentação de liquidez

Essa limitação pode impactar significativamente a estratégia de crescimento de um protocolo e a capacidade de alcançar novos usuários em cadeias emergentes. Os provedores de ponte podem priorizar o suporte a cadeias populares, enquanto negligenciam redes menores ou mais novas que podem ser estrategicamente importantes para o emissor do token.

Endereços inconsistentes de token de cadeia cruzada

Fornecedores de ponte de terceiros podem implantar tokens de ponte com endereços diferentes em cada cadeia devido às peculiaridades de sua pilha de tecnologia - por exemplo, sem suporte paraCREATE2. A falta de consistência de endereço, por sua vez, cria muitos problemas de UX:

• Riscos de segurança: Os usuários devem verificar os endereços de tokens diferentes em cada cadeia, aumentando o risco de interagir com tokens fraudulentos;
• Complexidade de integração: Os desenvolvedores devem manter listas de endereços de token válidos para cada rede;
• Risco aumentado de phishing: os atores mal-intencionados podem enganar mais facilmente os usuários com tokens falsos, já que não há um endereço consistente para verificar.

Essas desvantagens, combinadas com os problemas discutidos anteriormente de dependência de fornecedor, perda de soberania e alta exposição a falhas de ponte, destacam as limitações significativas de depender de pontes de terceiros canônicas para implantações de tokens cross-chain. Essa compreensão ajuda a preparar o terreno para entender por que soluções alternativas como o ERC-7281 são necessárias para enfrentar esses desafios de maneira mais abrangente.

3. Cunhar tokens canônicos através da ponte do emissor de tokens

Se um desenvolvedor quiser manter o controle máximo das implantações entre cadeias do token de um projeto, ele poderá gerenciar a emissão de representações canônicas do token em cadeias remotas. Isso é descrito como "confiar no emissor do token", já que o valor de cada representação em ponte do token está vinculado a tokens bloqueados na cadeia inicial do token pelo protocolo responsável por emitir a versão original do token na cadeia de origem.

Para que essa abordagem funcione, o emissor do token deve configurar uma infraestrutura para gerenciar a criação e a queima de tokens ponte de cadeia cruzada (garantindo que o fornecimento global permaneça sincronizado por meio de mapeamento canônico).

Exemplos notáveis de representações canônicas de um token emitido pelo criador do token são Teleport da MakerDAOe o da CircleProtocolo de Transferência Cruzada de Cadeia (CCTP)Teleport permite que os usuários movam DAI canônico entre Ethereum e vários rollups Ethereum via operações de caminho rápido e caminho lento. DAI é queimado em uma cadeia e emitido na cadeia de destino. CCTP funciona de forma semelhante e permite transferências de cadeia cruzada de USDC nativo (emitido pela Circle) por meio de um mecanismo de queima e emissão. Em ambos os casos, o emissor do token controla a emissão e queima de representações canônicas de um token.

Esta abordagem oferece controle completo de tokens bridged para protocolos. E resolve o problema de representações não fungíveis do mesmo token da maneira mais eficaz possível — apenas uma versão canônica do token (cunhada pelo emissor na cadeia de destino) existe, o que garante que os usuários tenham a mesma experiência ao usar um token em cada ecossistema que o emissor do token suporta.

Com essa abordagem, as aplicações também se beneficiam da eliminação da fragmentação de liquidez causada por representações não oficiais e conectadas de um token de protocolo flutuando no mesmo ecossistema. Os desenvolvedores também podem construir aplicações cross-chain mais robustas (por exemplo, trocas cross-chain e empréstimos cross-chain), já que as pontes do emissor de tokens canônicos permitem a movimentação eficiente de capital, sem interrupções e segura de tokens entre as cadeias.

A desvantagem das pontes de emissão de tokens canônicos, no entanto, é que esse modelo só é viável para projetos com capital suficiente para cobrir os custos de implantação de um token cadeia cruzada e a manutenção da infraestrutura (oráculos, guardiões, etc.) necessária para realizar a emissão e queima de tokens cadeia cruzada. Isso também tem o efeito indesejável de acoplar fortemente a segurança dos ativos vinculados com o modelo de segurança do protocolo.

Essa relação (entre as versões em ponte dos tokens de um protocolo e a segurança do protocolo) é amigável, já que a segurança dos tokens nativos que respaldam as representações canônicas já depende da segurança do protocolo, então os usuários e os desenvolvedores externos não estão assumindo novas suposições de confiança. Isso é especialmente verdadeiro de pontes de stablecoinoperado por emissores como Circle e Maker (agora Sky) - os usuários já confiam nos emissores de stablecoins para terem ativos suficientes para cobrir o resgate das stablecoins por moedas fiduciárias, portanto, confiar na segurança de uma ponte de stablecoin não é difícil.

Mas também representa um ponto central de falha - se a infraestrutura da ponte do emissor do token for comprometida, o valor de todas as representações canônicas circulando no ecossistema multi-chain está em risco. Isso também implica que apenas custodiantes centralizados (por exemplo, Circle no caso do USDC) podem implementar esse modelo de emissão de tokens ponte canônicos.

Considerações finais

Conforme mostrado neste relatório, a fungibilidade de ativos cross-chain é uma parte importante da interoperabilidade rollup com implicações para a experiência de movimentação entre diferentes cadeias. A capacidade dos tokens de permanecerem fungíveis ao serem transferidos para cadeias remotas também impacta a experiência do desenvolvedor, já que certos casos de uso dependem desta funcionalidade.

Foram propostas diferentes soluções para resolver o problema de tokens não fungíveis de cadeia cruzada - muitas das quais já abordamos neste relatório. Isso inclui a criação de tokens canônicos por meio de pontes nativas (consagradas), o uso de uma ponte dedicada de terceiros para criar tokens canônicos em várias cadeias e o uso de uma ponte de propriedade do protocolo para facilitar o movimento de tokens e preservar a fungibilidade.

Embora essas abordagens resolvam problemas específicos, elas falham em abordar todas as questões e usá-las para permitir a fungibilidade de ativos através de cadeias cruzadas requer alguns trade-offs indesejáveis. Será que podemos encontrar uma abordagem melhor? A resposta é sim.

O ERC-7281 é uma nova abordagem para a fungibilidade de ativos de cadeia cruzada que mitiga as compensações associadas às abordagens existentes. Também conhecido/a por xERC-20, O ERC-7281 permite que os protocolos implementem tokens canônicos de forma eficiente em várias cadeias sem comprometer a segurança, a soberania ou a experiência do usuário.

O design único da ERC-7281 permite que várias pontes (em lista branca) criem versões canônicas dos tokens de um protocolo em cada cadeia suportada, ao mesmo tempo que permite que os desenvolvedores do protocolo ajustem dinamicamente os limites de criação em uma base por ponte. Essa funcionalidade resolve muitos dos problemas associados às propostas históricas para tokens canônicos de várias cadeias, incluindo fragmentação de liquidez, alinhamento de incentivos, preocupações com a experiência do usuário, riscos de segurança da ponte, customização (de tokens de cadeia cruzada) e muito mais.

A próxima - e última - parte do nosso relatório em duas partes sobre a fungibilidade de ativos de cadeia cruzada abordará o ERC-7281 em detalhes e explorará como o padrão de token xERC-20 pode beneficiar desenvolvedores e usuários. Compararemos o ERC-7281 a outros designs para tokens canônicos multichain, exploraremos a abordagem do xERC-20 para tokens canônicos multichain e destacaremos considerações para protocolos e desenvolvedores que buscam construir sobre o padrão.

Fique atento!

Aviso Legal:

1. Este artigo é reproduzido a partir de [2077 Pesquisa]. Todos os direitos autorais pertencem ao autor original [Alex HookeEmmanuel Awosika]. Se houver objeções a essa reimpressão, por favor, entre em contato com o Gate Aprenderequipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.