Introdução

Os maxis modulares dizem que o futuro das criptomoedas é um milhão (ou mais) de domínios interconectados e utilizadores que saltam entre blockchains, tal como a Alice a percorrer o País das Maravilhas. Por que ficar preso a uma única cadeia se pode aceder a tecnologia de ponta, aplicações inovadoras, retornos de alto risco na participação/provisão de liquidez, alta performance e taxas de transação ultra baixas em outras blockchains?

Mas mudar entre blockchains é muito mais complicado do que a viagem de Alice pelo País das Maravilhas, principalmente devido às limitações inerentes às abordagens atuais de interoperabilidade blockchain (por exemplo, cadeias cruzadas). Em particular, as cadeias cruzadas de hoje são ou inseguras (mais de US$ 2,5 bilhões perdidos em ataques a pontes), lentas, caras ou limitadas em funcionalidade - ou exibem uma mistura de propriedades da lista.

Outras questões que afligem a indústria de pontes são mais sutis, mas ainda suficientes para transformar o sonho do maxi modular de um ecossistema multi-chain em um pesadelo para usuários e desenvolvedores - um exemplo disso é como tokens fungíveis (como ERC-20s) se tornam 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 exista o contrato de origem de um token: ERC-7281: Tokens Soberanos-Bridged.

ERC-7281 estende o ERC-20 - o padrão de facto para a criação de tokens fungíveis no Ethereum - para permitir a cunhagem e queima de representações canônicas de tokens ERC-20 em domínios remotos por várias pontes aprovadas pelos emissores de tokens. Isso garante que os usuários que atravessam 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 cruzados por diferentes rotas/pontes. Importante salientar que os protocolos que adotam o ERC-7281 mantêm o controle dos tokens atravessados (ao contrário do status quo em que a ponte controla um token atravessado) e podem limitar a taxa de cunhagem para reduzir a exposição no caso de falha de uma ponte.

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

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 através da ponte canônica. Mesmo que esses dois tokens sejam emitidos pela mesma entidade e tenham o mesmo preço, eles são tecnicamente diferentes, tokens infungíveis e, portanto, não são “interoperáveis”—enquanto o USDC nativo pode ser transferido via a ponte CCTP da Circle, o USDC transferido só pode ser transferido de volta para o L1 através da ponte canônica.

A ERC-7281 resolve isso, introduzindo uma extensão do ERC-20 onde os implementadores do token podem atribuir e parametrizar diferentes fontes de pontes para ele. No exemplo acima, a Circle poderia implementar um token USDC universal em todos os 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 os cunhadores serem hackeados, 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 fungíveis de cadeia cruzada, ele corrige problemas associados a propostas anteriores - como a dependência de fornecedores, a perda de soberania para emissores de tokens, altos custos para inicialização de liquidez para tokens de ponte, sobrecarga de infraestrutura e aumento da exposição a falhas de ponte.

Este relatório em duas partes irá analisar a justificação para a introdução de um padrão de token soberano com ponte e fornecer uma visão abrangente da especificação ERC-7281 (também conhecida como xERC-20). Também iremos discutir os benefícios positivos e as potenciais desvantagens da implementação do ERC-7281 para utilizadores, programadores, fornecedores de infraestrutura e outros intervenientes no ecossistema Ethereum.

Uma atualização sobre pontes de blockchain

Antes de mergulhar no problema dos tokens ponte não fungíveis, ajuda a entender por que os tokens ponte existem em primeiro lugar. Isso, por sua vez, requer entender a motivação e a operação das pontes de blockchain—visto 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 criação

• Um usuário deseja fazer a ponte de um token de sua cadeia nativa ou de 'casa' (onde foi emitido inicialmente) para outra cadeia. As duas blockchains não são interoperáveis, pois cada cadeia 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 cauciona tokens depositados pelo utilizador na cadeia de origem num contrato inteligente e cria uma representação "embrulhada" do token nativo através de um contrato de token implantado na cadeia de destino.
• Quando o usuário deseja fazer a ponte na direção inversa (cadeia de destino → cadeia de origem), eles devolvem os tokens envolvidos à 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, em seguida, 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;
• Isto mantém o fornecimento total de tokens enquanto permite transferências de cadeia cruzada.

trocas atômicas

• Esta abordagem troca diretamente ativos na cadeia de origem por ativos na cadeia de destino com outra parte.
• As trocas atômicas funcionam através do bloqueio mútuo de fundos com o mesmo valor secreto para desbloqueá-los, o que significa que se o segredo for revelado de um lado, também pode ser revelado do outro. Isso confere às trocas a propriedade de atomicidade.
• A atomicidade significa que a troca é concluída totalmente (em ambos os lados) ou não é concluída de forma alguma, evitando fraudes ou transferências parciais/fracassadas.

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

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

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 o resultado desejado na cadeia de destino (sua 'intenção'). Operadores especializados chamados 'preenchedores' ou 'solucionadores' podem cumprir essa intenção enviando os tokens solicitados ao usuário na cadeia de destino antecipadamente. Os operadores então comprovam a ocorrência da transferência para reivindicar os fundos bloqueados na cadeia de origem como reembolso.

Algumas pontes baseadas em intenções utilizam mecanismos de bloqueio e cunhagem por baixo. Neste caso, a ponte cunha tokens embrulhados que são enviados quer para o preenchedor que cumpriu a intenção do usuário—ou diretamente para o usuário se nenhum preenchedor interveio. Enquanto as pontes baseadas em intenções adicionam uma camada extra de eficiência através da sua rede de solucionadores, ainda dependem fundamentalmente dos mesmos princípios que as pontes tradicionais de bloqueio e cunhagem.

Podemos pensar em cada token envolvido, quer seja 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 pedidos dos detentores para retirar os tokens nativos mantidos em garantia na cadeia de origem do token.

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

Por que precisamos de pontes?

A capacidade de transacionar com uma versão sintética de um ativo numa cadeia remota — possibilitada por pontes que criam representações do ativo — é uma funcionalidade poderosa e permite que os programadores e utilizadores possam utilizar os benefícios da interoperabilidade entre cadeias cruzadas. Alguns destes benefícios incluem o acesso a maior liquidez, exposição a novos utilizadores e flexibilidade para os utilizadores (que podem interagir com as suas aplicações favoritas de diferentes cadeias sem fricção).

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

BobDEX é uma bolsa automatizada de criadores de mercado (AMM) que Bob criou na Ethereum para permitir trocas sem confiança entre diferentes ativos. BobDEX tem um token nativo, $BOB, que funciona como um token de governança e um token de recompensa LP. Neste último caso, o BobDEX emite tokens BOB para provedores de liquidez (LPs), dando aos usuários que fornecem liquidez a uma pool direito a uma percentagem das taxas pagas pelos usuários da 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 adicional. 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 ter 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) de baixa taxa e alta capacidade) e implanta uma versão embrulhada do token BOB (wBOB) na L2 através da ponte Arbitrum-Ethereum. O BobDEX na Arbitrum é idêntico ao BobDEX no Ethereum, exceto que ele usa wBOB - não tokens nativos BOB - para recompensas de LP e governança.

A diferença entre os tokens de aplicação (BOB envolvido vs. BOB nativo) não faz diferença do ponto de vista dos utilizadores (por exemplo, fornecedores de liquidez) que interagem com o BobDEX no Arbitrum. Uma vez que os tokens wBOB são apoiados 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 da ponte.

A situação é uma vitória para Bob e os utilizadores:

1. Bob pode atrair mais utilizadores, especialmente utilizadores que desejam taxas de gás baixas e confirmações de transações 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 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 ao aprimoramento da inovação componível e à desbloqueio de novos casos de uso que aproveitam a liquidez de um token conectado. Por exemplo, Alice pode criar um protocolo de empréstimo chamado AliceLend no Arbitrum que aceita wBOB como garantia dos mutuários para expandir a utilidade do wBOB e criar um novo mercado paraempréstimo e empréstimo.

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

A ponte de cadeia cruzada, na sua forma atual, tem proporcionado uma solução viável para garantir interoperabilidade entre (anteriormente isolados) Ethereum L2se facilitar novas aplicações (por exemplo, empréstimos entre cadeias e DEXes entre cadeias). No entanto, o ecossistema de pontes está atualmente lidando com limitações que impedem um maior crescimento, como a não fungibilidade de tokens entre cadeias - vamos explorar esse problema em detalhe posteriormente.

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

O fluxo de ponte de bloqueio e cunhagem 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 envolvidas de um token de ponte sejam sempre apoiadas por tokens nativos bloqueados na cadeia de origem. Se um atacante criar representações de um token em uma cadeia remota sem depositar tokens nativos na cadeia de origem, ele pode tornar a ponte insolvente trocando (fraudulentamente criados) tokens envolvidos por tokens nativos na cadeia principal e impedindo que usuários legítimos - que depositaram no contrato de ponte antes de criar tokens envolvidos - retirem os depósitos.

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

• Alice transmite USDC da Ethereum para o Arbitrum através da ponte canónica do Arbitrum e recebe 200 USDC.e no Arbitrum, enquanto Bob transmite USDC para o Arbitrum através da Axelar e recebe 200 axlUSDC no 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 a Ethereum.
• Bob tenta sacar 400 USDC via axlUSDC e recebe apenas 200 USDC, juntamente com uma mensagem explicando que a ponte tem apenas 200 USDC para dar a Bob. Bob está confuso, pois os tokens ERC-20 envelopados 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 entre cadeias: “token ERC-20 fungível” nem sempre significa “pode trocar este token 1:1 com outros tokens ERC-20 em várias aplicações”. A tentativa de Bob de fazer negócios arriscados com Alice — arriscados porque Alice pode não devolver os tokens — corre espetacularmente mal.

Bob depois de ser sacudido numa troca

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

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

O dilema de Bob e Alice aponta para um problema na ligação entre domínios onde múltiplas representações não fungíveis de um ativo subjacente são cunhadas por fornecedores de pontes concorrentes. O outro problema com diferentes representações ERC-20 do mesmo ativo é que elas não podem ser negociadas em um único pool de liquidez.

Usando o exemplo anterior, se tivermos axlUSDC e USDC.e na cadeia e quisermos trocá-los em ETH e vice-versa, devemos implantar dois pools de liquidez — ETH/axlUSDC e ETH/USDC.e. Isso leva a um chamado probem de "fragmentação de liquidez" – uma situação em que os pools de negociação têm liquidez menor do que poderiam ter 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 retire da ponte na cadeia de origem. Ter um token canônico por cadeia também beneficia os desenvolvedores, pois os usuários podem mover rapidamente entre ecossistemas sem lidar com problemas relacionados à liquidez do token.

Então, como implementamos versões canônicas de um token em cada cadeia em que 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 várias cadeias.

Implementar 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 entre diferentes cadeias sem problemas de fungibilidade; você tem quatro opções:

1. Mint tokens canónicos através de pontes rollup/sidechain canónicas
2. Mintar tokens canónicos através de um fornecedor de ponte de terceiros
3. Criar tokens canónicos através de uma ponte de emissão de tokens
4. Emissão direta de várias cadeias com atomic swaps

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

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

1. Criar tokens canônicos através de pontes de rollup/sidechain canônicos

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 roteadas através da ponte canônica da cadeia (depósitos e saques) são tipicamente validadas pelo conjunto de validadores da cadeia, o que proporciona garantias mais sólidas de que os depósitos na cadeia principal apoiam de forma credível todas as representações cunhadas.

Embora a ponte canónica esteja a criar a representação canónica de um token, outras representações ainda vão existir. Isto acontece simplesmente porque as pontes canónicas muitas vezes têm limitações que impedem que ofereçam aos utilizadores a melhor experiência. Por exemplo, fazer uma ponte do Arbitrum/Optimism para o Ethereum através da ponte canónica do rollup implica um atraso de sete dias, uma vez que as transações têm de ser validadas por verificadores — e possivelmente contestadas por umprova de fraude, se inválido—antes da camada de liquidação do rollup (Ethereum—liquida um lote de transações.

Os utilizadores de rollup que desejam saídas mais rápidas devem utilizar outros fornecedores de ponte que possam assumir a propriedade das saídas de rollup pendentes e fornecer liquidez antecipada na cadeia de destino desejada pelo utilizador. Quando essas pontes utilizam 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.

As sidechains com conjuntos de validadores independentes têm menor latência, uma vez que as retiradas são executadas assim que o protocolo de consenso da sidechain confirma um bloco contendo uma transação de retirada. A ponte PoS da Polygon é um exemplo de uma ponte canônica que conecta uma sidechain a diferentes domínios (incluindo rollups do Ethereum e a mainnet do Ethereum).

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

No entanto, as pontes de sidechain também têm uma fraqueza em comum com as pontes canônicas de rollup: os usuários só podem fazer pontes entre um par de cadeias conectadas. Eles não podem fazer pontes para outras blockchains usando a ponte canônica. Por exemplo, você não pode fazer uma ponte do Arbitrum para o Optimism hoje usando a Arbitrum Bridge ou fazer uma ponte do Polygon para o 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 apresenta 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, as pontes de liquidez aprovadas (a) emitem representações embrulhadas de um token do protocolo na cadeia de origem (b) trocam tokens embrulhados pela representação canónica no destino através de uma piscina 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 existam exceções (como veremos mais tarde). Por exemplo, a versão canônica do USDT na Optimism é o opUSDT cunhado pela Ponte Optimism.

Cada ponte de liquidez funciona como uma DEX com um Fabricante de Mercado Automatizado (AMM) para executar trocas entre pares de ativos depositados em diferentes pools de liquidez. Para incentivar a oferta de liquidez, os pools AMM compartilham uma parte das taxas de troca com os detentores que bloqueiam tokens canônicos nos contratos de pool.

Este é semelhante ao modelo da Uniswap; a única diferença perceptível é que os pares de ativos são geralmente a representação da ponte de liquidez de um token contra a representação canônica. Por exemplo, um usuário que cria uma ponte para USDT na Optimism via Hop terá que trocar hUSDT na Optimism via o pool huSDT:opUSDT.

O fluxo de trabalho para interligação através de uma ponte de liquidez será o seguinte:

• Bloquear tokens nativos na cadeia de origem
• Representação de ponte de cunhagem de token nativo na cadeia de destino
• Trocar a representação em ponte pela representação canônica na cadeia de destino através da piscina AMM
• Enviar tokens canônicos para o usuário

Este 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 várias 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 por meio do AMM antes de queimar essa representação e fornecer o recibo de prova de queima. Uma vez confirmado, o usuário pode sacar os tokens nativos bloqueados no início. (Assim como na operação anterior, os detalhes complexos 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 de rollup; por exemplo, a Hop permite que partes especializadas conhecidas como "Bonders" atestem a validade da transação de retirada de um usuário na L2 e antecipem o custo de retirada 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 aos utilizadores moverem-se entre mais cadeias, ao contrário das pontes canónicas; por exemplo, a Hop permite aos utilizadores moverem-se entre Arbitrum e Optimism sem terem de retirar primeiro para o Ethereum. Tal como a transferência rápida de L2 para L1, a transferência rápida de L2 para L2 requer que os Bonders executem um nó completo para a cadeia L2 de origem para confirmar as retiradas antes de avançar com o custo de cunhar tokens para um utilizador na cadeia L2 de destino. Isto permite mais composição entre rollups e melhora drasticamente a experiência do utilizador, uma vez que os utilizadores 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. Derrapagem

Deslizamento é uma diferença na quantidade de tokens esperados e recebidos ao interagir com um AMM. O deslizamento ocorre devido ao preço dos swaps dos AMMs 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 depois que uma troca é concluída, o que pode mudar entre o momento em que um usuário inicia uma negociação e a execução da troca.

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

Isso também afeta os desenvolvedores que constroem aplicações de cadeia cruzada, pois devem ter em conta casos limite em que ocorre deslize; o utilizador não pode concluir uma operação de cadeia cruzada devido a receber quantidades inferiores de um token em uma ou mais cadeias de destino.

Aplicações como agregadores de ponte (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 reverter transações, os usuários sempre perdem uma porcentagem do token transferido — independentemente da liquidez nas pools 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 pelos ativos bloqueados, as pontes de liquidez dependem de tokens disponíveis em pools AMM para completar transferências entre cadeias. Quando a liquidez cai abaixo de limites críticos, todo o mecanismo de ponte pode efetivamente deixar de funcionar.

• As operações de ponte podem parar completamente se a liquidez diminuir muito, impedindo os utilizadores de completar as suas transferências pretendidas;
• Os usuários podem ser obrigados a dividir transferências grandes em transações menores para evitar o esgotamento da liquidez da pool;
• Durante períodos de alta volatilidade ou stress no mercado, os provedores de liquidez podem retirar-se 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.

O requisito de liquidez cria uma dependência circular: as pontes precisam de liquidez substancial para funcionar de forma confiável, mas atrair fornecedores de liquidez requer demonstrar o uso consistente da ponte e a geração de taxas. Este problema do ovo e da galinha é particularmente agudo para tokens novos ou menos frequentemente negociados, 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 trocas da representação da ponte para o token canônico na cadeia de destino sem que os usuários incorram em deslizamento excessivo; 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, ao emitir um token, priorizam pontes com base na quantidade de liquidez e custos de transação.

Embora isso garanta que os usuários que estão a fazer a ponte entre os tokens de um projeto ou a usar um agregador de pontes para enviar tokens em cadeia cruzada tenham uma melhor UX, a seleção de pontes com base na liquidez coloca as pontes incapazes de gastar em incentivos de provedor de liquidez (LP) em desvantagem. Além disso, a seleção de 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 nas transações de ponte. Em ambos os casos, as pontes não estão competindo no que é, provavelmente, a métrica mais importante: a segurança.

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

4. UX de ponte pobre

As pontes de liquidez são uma melhoria em relação às pontes canônicas, mas também têm problemas de interface do usuário. Além de sofrerem deslizamento em trocas de cadeia cruzada, os usuários podem não conseguir concluir 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 liquidez existirá para um par de ativos quando a mensagem do usuário para trocar os tokens chegar à cadeia de destino, então esse caso é principalmente inevitável.

Os utilizadores têm duas opções nesta situação (ambas subótimas):

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

2. Criar tokens canónicos através de uma ponte de terceiros canónicos

Um dapp multi-cadeia pode contornar o problema de tokens de ponte não fungíveis selecionando uma única ponte para criar representações canônicas do token do dapp em cada cadeia onde o dapp é implantado. Assim como pontes canônicas que criam representações aprovadas do token de um projeto, essa abordagem requer mapear 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 de ponte deve rastrear a criação e destruição de um token e garantir que as operações de criação e destruição permaneçam sincronizadas com o fornecimento de tokens na cadeia principal.

Usar um único provedor de ponte oferece mais flexibilidade para as equipes de projeto, especialmente porque as pontes de terceiros têm incentivo para apoiar a interligação entre uma gama mais ampla de ecossistemas em comparação com as pontes canônicas que conectam no máximo uma cadeia. Se uma ponte existe em todas as cadeias onde uma aplicação é implantada, os usuários podem mover-se rapidamente entre cadeias cruzadas sem precisar sacar de volta para a cadeia de origem; um provedor de ponte só precisa garantir que os tokens cunhados na cadeia de destino A sejam queimados antes que um usuário cunhe tokens na cadeia de destino B e tokens canônicos na cadeia B sejam (re)mapeados para o token na cadeia de origem.

O problema dos tokens pontes não fungíveis também é eliminado; desde que os utilizadores façam a ponte através do fornecedor de pontes aprovado, podem sempre trocá-los 1:1 por outros tokens pontes. Esta abordagem resolve ainda mais os problemas da ponte baseada na liquidez no modelo de ponte canónica:

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

Alguns exemplos de tokens fornecidos por uma única ponte na natureza incluem o Token Fungível Omnichain (OFT) da LayerZero, o Serviço de Token Interchain (ITS) da Axelar, o xAsset da 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. Esse detalhe sutil destaca alguns problemas com essa abordagem para o tratamento de tokens conectados. Nomeadamente os seguintes:

• Dependência de fornecedor
• Perda de soberania
• Alto índice de exposição a falhas em pontes
• Perda das características personalizadas do token nas cadeias de destino
• Ser 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 torná-los vulneráveis ​​a phishing

Desvantagens de usar pontes de terceiros canônicas

1. Vendor lock-in

Selecionar um único fornecedor de ponte para criar representações canônicas em uma ou mais cadeias expõe os desenvolvedores ao risco de ficarem presos a um fornecedor. Como cada fornecedor de ponte cria uma representação proprietária compatível apenas com sua própria infraestrutura (e projetos integrados ao ecossistema), o modelo de fornecedor de ponte única trava efetivamente um emissor de token em 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) tenha emitido um token (BobToken) no Ethereum e escolha o LayerZero OFT para criar versões canônicas de BobToken no Optimism, Arbitrum e Base. BobToken tem um suprimento fixo de 1.000.000 de tokens e os tokens transferidos via ponte LayerZero representam 50% do total de BobTokens em circulação.

A disposição de negócios prossegue sem problemas até que Bob decida que os usuários estão melhor ao fazer a ponte para BobTokens por meio de um serviço de ponte concorrente (por exemplo, Axelar). No entanto, Bob não pode simplesmente dizer: 'Estou mudando para Axelar ITS para criar representações canônicas de BobToken em Optimism, Base e Arbitrum'; uma vez que os tokens OFT e os tokens ITS são incompatíveis, Bob corre o risco de criar problemas tanto para os antigos usuários quanto para os novos usuários, já que dois BobTokens podem não ser 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 representações embrulhadas do BobToken cunhadas através do LayerZero, enviando uma transação que queima tokens OFT em ponte e desbloqueia BobTokens no Ethereum. Os usuários agora podem mudar para a nova representação canônica do BobToken bloqueando tokens com Axelar no Ethereum e recebendo BobTokens canônicos (mapeados para o fornecimento do contrato de token no Ethereum) na cadeia de destino. Isso é dispendioso e incorre em coordenação maciça e sobrecarga operacional para as equipes de gerenciamento de projetos DAO, portanto, aderir ao provedor escolhido geralmente é a opção mais segura.

No entanto, isso deixa desenvolvedores como o Bob em uma posição problemática, pois o bloqueio do fornecedor torna impossível a troca se um provedor de ponte deixar de cumprir os termos do acordo, tiver um conjunto de recursos limitado, não tiver integrações abrangentes no ecossistema, oferecer uma experiência do usuário ruim, etc. Também 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 tokens do Bob sem motivos claros, aumentar as taxas de ponte ou até mesmo censurar operações de ponte. As mãos do Bob estão amarradas neste caso, pois fazer uma ruptura completa de uma ponte de terceiros canônica com defeito é tão complexo quanto manter o relacionamento comercial.

2. Perda de soberania para protocolos

A parte concluinte da seção anterior sobre aprisionamento do fornecedor destaca outro problema ao usar uma ponte de terceiros canônica: os emissores de tokens abrem mão do controle dos tokens canônicos da ponte em troca de maior conveniência e melhorias na experiência do usuário. Para usar o exemplo anterior: o BobToken no Ethereum está totalmente sob o controle de Bob, pois ele controla o contrato do token ERC-20 subjacente, mas o BobToken no Optimism, Arbitrum e Base é controlado pela LayerZero, que possui o contrato OFT que emite as 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 pode nem sempre ser o caso. Nos piores cenários, o comportamento do BobToken no Ethereum pode divergir significativamente do comportamento do BobToken no 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 pontes

Na primeira abordagem, onde os tokens são bridged cross-chain 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 retirar até a liquidez máxima disponível para o ativo envolvido em pools de liquidez (por exemplo, criando cUSDT no Optimismo → trocando cUSDT por opUSDT canônico → retirando opUSDT para o Ethereum via ponte rápida → trocando por USDT nativo no Ethereum).

No modelo de ponte canônica de terceiros, o risco para um emissor de token proveniente de uma exploração que afeta a ponte parceira é equivalente à quantidade total de tokens que um atacante cunha em cadeias remotas onde a ponte afetada possui uma implantação. Isso é possível porque toda 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 crie 1000 tokens (onde o token é inicialmente emitido na cadeia A) sem depositar garantia. Os tokens do atacante na cadeia B não são mapeados para o contrato da cadeia principal, portanto, não é possível retirá-los da cadeia A. Ainda assim, ele pode conectar-se à 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 se originam do mesmo serviço de ponte. Os tokens da cadeia C são mapeados para o contrato da cadeia principal, pois foram criados legitimamente por usuários que bloquearam tokens na cadeia A (a cadeia principal do token), permitindo que o atacante queime tokens na cadeia C e retire tokens nativos na cadeia A e, potencialmente, conclua o itinerário trocando os tokens por meio de uma saída CEX ou fiat.

(Origem)

Perda de recursos de token personalizados

Ao utilizar 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 ocorre porque os provedores de ponte costumam 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 votos (ZK), mecanismos de rebase (stETH, USDM), recursos de taxa sobre transferência (memecoins), funções de lista negra e lista branca (USDT, USDC), transferências pausadas e regras ou permissões especiais de cunhagem são frequentemente removidos quando os tokens são conectados por meio de um provedor de terceiros, já que a versão em ponte normalmente usará uma implementação básica do ERC-20. Essa perda de funcionalidade cria inconsistências em 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 seja mais simples do ponto de vista do fornecedor da ponte, reduz efetivamente as capacidades do token e pode prejudicar a capacidade do emissor de manter um comportamento consistente do token em todo o ecossistema multi-cadeia de sua aplicação. Tais problemas podem tornar as expansões de cadeia cruzada um pesadelo para os desenvolvedores e representar um obstáculo para realizar o sonho de aplicativos em várias cadeias.

Cadeias suportadas limitadas

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 de tokens deseja expandir, eles enfrentam duas opções subótimas:

• Aguarde que o provedor de ponte adicione 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 do ZKsync Era que levou muitos dapps a nunca implantarem nele)
• Utilize um provedor de ponte diferente para essa cadeia específica, o que reintroduz o problema dos tokens não fungíveis e da fragmentação da liquidez

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

Endereços de token de cadeia cruzada inconsistentes

Os 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. Falta de consistência de endereços, por sua vez, cria muitos problemas de UX:

• Riscos de segurança: os usuários devem verificar os endereços diferentes de token em cada cadeia, aumentando o risco de interagir com tokens fraudulentos;
• Complexidade da 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 utilizadores com tokens falsos, já que não há um endereço consistente para verificar.

Estas 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 confiar em pontes de terceiros canônicas para implantações de token cross-chain. Esta compreensão ajuda a preparar o terreno para entender por que soluções alternativas como ERC-7281 são necessárias para abordar esses desafios de uma maneira mais abrangente.

3. Criar tokens canónicos através da ponte do emissor de tokens

Se um desenvolvedor deseja manter o controle máximo das implantações de cadeia cruzada do token de um projeto, pode gerenciar a emissão de representações canônicas do token em cadeias remotas. Isso é descrito como "confiar no emissor do token", pois o valor de cada representação da ponte do token está ligado aos tokens bloqueados na cadeia de origem do token pelo protocolo responsável pela emissão da 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 bridged cross-chain (garantindo ao mesmo tempo que o fornecimento global permaneça em sincronia 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 do Circle'sProtocolo de transferência entre cadeias (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 cunhado na cadeia de destino. CCTP funciona de maneira semelhante e permite transferências cruzadas de USDC nativo (emitido pela Circle) entre cadeias através de um mecanismo de queima e cunhagem. Em ambos os casos, o emissor do token controla a cunhagem e queima de representações canônicas de um token.

Essa abordagem oferece controle completo de tokens em ponte para protocolos. E corrige o problema das representações não fungíveis do mesmo token da maneira mais eficaz possível — existe apenas uma versão canônica do token (cunhada pelo emissor na cadeia de destino), o que garante que os usuários tenham a mesma experiência usando um token em todos os ecossistemas suportados pelo emissor do token.

Com essa abordagem, as aplicações também se beneficiam da eliminação da fragmentação da liquidez causada por representações não oficiais e conectadas de um token de protocolo flutuando no mesmo ecossistema. Os desenvolvedores também podem criar aplicativos de cadeia cruzada mais robustos (por exemplo, trocas de cadeia cruzada e empréstimos de cadeia cruzada), pois as pontes do emissor de token canônico permitem a movimentação eficiente de capital, sem interrupções e segura de tokens entre cadeias.

No entanto, a desvantagem das pontes de emissão de tokens canónicos é que este modelo só é viável para projetos com capital suficiente para cobrir os custos de implantação de um token de cadeia cruzada e manter a infraestrutura (oráculos, keepers, etc.) necessária para realizar a criação e queima de tokens em cadeias cruzadas. Isso também tem o efeito indesejável de acoplar de forma estreita a segurança dos ativos transferidos com o modelo de segurança do protocolo.

Essa relação (entre versões em ponte dos tokens de um protocolo e a segurança do protocolo) é amigável, uma vez que a segurança dos tokens nativos que suportam representações canônicas já depende da segurança do protocolo, portanto, usuários e desenvolvedores externos não estão assumindo novas suposições de confiança. Isto é especialmente verdade para pontes de stablecoinoperado por emissores como a Circle e a Maker (agora Sky) - os utilizadores já confiam nos emissores de stablecoins para terem ativos suficientes para cobrir a troca de stablecoins por moedas fiduciárias, por isso 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 em circulação no ecossistema multichain está em perigo. Isso também implica que apenas custódios centralizados (por exemplo, a Circle no caso do USDC) podem implementar esse modelo de emissão de tokens ponte canônicos.

Pensamentos finais

Conforme mostrado neste relatório, a fungibilidade de ativos de cadeia cruzada é uma parte importante da interoperabilidade de rollup com implicações para a experiência de mover-se entre diferentes cadeias. A capacidade dos tokens de permanecerem fungíveis ao serem conectados a cadeias remotas também afeta a experiência do desenvolvedor, pois alguns casos de uso dependem dessa funcionalidade.

Foram propostas diferentes soluções para resolver o problema de tokens de cadeia cruzada infungíveis - muitas das quais abordamos neste relatório. Isso inclui a criação de tokens canônicos por meio de pontes nativas (consagradas), o uso de uma ponte de terceiros dedicada 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 não conseguem abordar todas as questões e usá-las para permitir a fungibilidade de ativos entre cadeias requer algumas compensações indesejáveis. Podemos encontrar uma abordagem melhor? A resposta é sim.

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

O design único do ERC-7281 permite que várias pontes (listadas em whitelist) criem versões canônicas dos tokens de um protocolo em cada cadeia suportada, permitindo 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 multi-cadeias, incluindo fragmentação de liquidez, alinhamento de incentivos, preocupações com a experiência do usuário, riscos de segurança das pontes, 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 desejam construir com base no padrão.

Fique atento!

Aviso Legal:

1. Este artigo é reproduzido de [2077 Investigação]. Todos os direitos de autor pertencem ao autor original [Alex Hook e Emmanuel Awosika]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipe e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe de aprendizado da Gate. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.