Comparando Estruturas de Token

AvançadoOct 09, 2024
Neste artigo, vamos comparar os principais frameworks de token oferecidos por diferentes protocolos de interoperabilidade. O objetivo é avaliar suas características únicas, pontos fortes e compensações para ajudar as equipes a escolher a melhor solução para emitir tokens nativamente multi-cadeia.
Comparando Estruturas de Token

Introdução

Emitir um token costumava ser simples: você o implantaria no Ethereum, onde toda a ação estava - usuários, negociantes, capital e liquidez. Hoje, o cenário é muito mais complexo. A liquidez está espalhada por Bitcoin, Ethereum, L2s, Solana e outras cadeias. Então, onde você deve emitir seu token? Não há uma resposta clara.

Mas e se você não tivesse que escolher apenas uma cadeia? Imagine um token que funciona em todos os lugares, fluindo perfeitamente por toda a economia criptográfica.

Graças aprotocolos de interoperabilidade (também conhecidas como pontes), agora é possível emitir tokens com um mercado unificado que abrange várias cadeias. Isso cria liquidez global sem fronteiras, simplificando as operações para emissores de tokens: mais liquidez, maior adoção e efeitos de rede mais fortes - sem as dores de cabeça da fragmentação. Essencialmente, é como ter uma conta bancária global que funciona em todos os lugares, integrada em todos os ecossistemas DeFi.

Neste artigo, vamos comparar os principais frameworks de token oferecidos por diferentes protocolos de interoperabilidade. O objetivo é avaliar suas características únicas, pontos fortes e compensações para ajudar as equipes a escolher a melhor solução para emitir tokens nativamente multi-chain.

Vamos explorar os seguintes frameworks:

  • Serviço de Token Interchain (ITS) da Axelar
  • Transferências do Token Nativo do Wormhole (NTT)
  • Token Fungível Omnichain da LayerZero (OFT)
  • Token de Warp da Hyperlane
  • xERC20 (EIP 7281: Tokens Transponíveis Soberanos)

Vamos mergulhar.

Como funcionam os frameworks de Token

As estruturas de token operam de duas maneiras principais, dependendo se você está tornando um token existente multi-cadeia ou lançando um token nativamente multi-cadeia desde o início.

Burn-and-Mint: Para Tokens Nativos de Múltiplas Cadeias

Quando um Token é emitido nativamente em várias cadeias a partir do Dia 1, o seu fornecimento é distribuído por essas cadeias. Quando os Tokens são movidos entre cadeias, eles são queimados na cadeia de origem e cunhados na cadeia de destino, garantindo que o fornecimento total permaneça constante.

Pense nisso como um sistema de contabilidade (como muitas equipes de interoperabilidade explicaram). Aqui está um exemplo: considere o Token X com um fornecimento total de 1000 tokens, distribuídos com base na demanda em cinco cadeias:

  • Cadeia A: 400 tokens
  • Chain B: 200 tokens
  • Chain C: 200 tokens
  • Chain D: 100 tokens
  • Chain E: 100 tokens

Se um usuário transferir 50 tokens da Cadeia E para a Cadeia A, esses tokens serão gravados na Cadeia E e cunhados na Cadeia A. A distribuição atualizada seria:

  • Chain A: 450 tokens
  • Cadeia B: 200 tokens
  • Chain C: 200 tokens
  • Chain D: 100 tokens
  • Chain E: 50 tokens

Este processo garante que o fornecimento total permaneça em 1000 tokens, facilitando transferências sem falhas entre cadeias.

Travar e Criar: Para Tokens Existente

Para tokens já existentes que foram inicialmente implantados em uma única cadeia, o processo é ligeiramente diferente. Todo o fornecimento existe em uma única cadeia e, ao transferir para outra cadeia, parte do fornecimento é bloqueado em um contrato inteligente na cadeia de origem, enquanto uma quantidade equivalente é criada na cadeia de destino.

Este método é semelhante à forma como os tokens envolvidos operam. Tokens bloqueados na Chain A podem então ter uma versão envolvida cunhada na Chain B. No entanto, agora estes tokens também podem mover-se da Chain B para a Chain C usando o método de queimar-cunhar, sem necessidade de serem bloqueados em várias chains. O fornecimento original permanece na Chain A, garantindo que as transferências entre as chains simplesmente envolvam a verificação de que os tokens queimados correspondem aos cunhados.

Por que os Frameworks de Token são Importantes

Aqui está o motivo pelo qual ter um token negociável em um mercado unificado que abrange várias cadeias beneficia as equipas:

  • Liquidez - Um único mercado atrai mais traders, aumentando a liquidez.
  • Consciência da marca — Os Tokens tornam-se acessíveis em vários ecossistemas DeFi, aumentando a demanda e o reconhecimento da marca.
  • Simplicidade — A gestão de Token torna-se mais fácil, reduzindo a complexidade.
  • Redundância - Se uma cadeia falhar, os tokens ainda podem operar em outras, fornecendo uma rede de segurança.
  • Expansão de mercado — O token pode ser implantado em várias cadeias mais rapidamente, impulsionando a adoção. Além disso, ecossistemas interligados significam mais espaço para experimentação em DeFi.
  • Efeitos de rede - Colaboração com outros projetos aumenta a adoção e o valor.

ConsiderarProtocolo de Transferência Cross-Chain da Circle (CCTP)Ao lançar CCTP, a Circle permitiu que o USDC fosse negociado de forma transparente em todas as cadeias suportadas, abordando questões-chave:

  • Sem liquidez fragmentada - Antes, você tinha diferentes versões de USDC em cada cadeia, o que levava à ineficiência. Agora, o USDC é o mesmo em todas as cadeias.
  • Expansão do mercado - A implementação do USDC em várias cadeias dá-lhes acesso a mais utilizadores e mercados.
  • Eficiência de capital — Os usuários podem fazer a ponte de grandes quantidades de USDC sem necessidade de pools de liquidez ou wrapping.
  • Taxas mínimas - As transferências custam pouco além das taxas de gás.
  • Sem deslizamento - As transferências são diretas e eliminam o risco de deslizamento.

A característica única do Circle para o USDC deve-se à sua ponte personalizada, CCTP, um luxo que a maioria dos projetos não possui. Aqui é onde entram em jogo os frameworks de token mantidos por protocolos de interoperabilidade. Estes frameworks fornecem uma solução semelhante ao que a CCTP oferece para o USDC, mas para qualquer token. Ao emitir um token através destes frameworks, os projetos podem criar um mercado unificado em várias cadeias suportadas, permitindo transferências fáceis utilizando mecanismos de queima/bloqueio e mint.

Comparação de Estruturas de Token

Agora que entendemos como funcionam as estruturas de token e seus benefícios, vamos comparar as várias soluções disponíveis no mercado para equipes que buscam emitir seus tokens.

Segurança

Aqui está uma explicação dos aspectos críticos de segurança abordados na tabela:

1. Mecanismo de verificação

O mecanismo de verificação está no cerne de como as transferências são validadas através das cadeias. Refere-se à forma como as mensagens são verificadas e ao tipo de configuração em termos de mecanismos de verificação que cada estrutura fornece - seja uma opção única, um sistema modular com várias opções ou um design flexível compatível com qualquer ponte - permitindo que os emissores de tokens selecionem a solução mais adequada com base em seus requisitos de segurança.

Embora os mecanismos de verificação personalizados ofereçam benefícios, são as configurações padrão quepermanecer o mais amplamente utilizado. Portanto, é importante focar na segurança dos esquemas de verificação padrão. Recomenda-se que as equipes usem esquemas de verificação adicionais além dos padrões para aprimorar sua configuração de segurança.

Quando se trata de vivacidade, confiar em múltiplos esquemas de verificação tem tanto benefícios como inconvenientes. Do lado positivo, há uma melhor tolerância a falhas: se um fornecedor enfrentar tempo de inatividade, outros podem garantir operações contínuas, melhorando a fiabilidade do sistema. No entanto, isso também aumenta a complexidade do sistema. Cada esquema adicional introduz um potencial ponto de falha, aumentando o risco de interrupções operacionais.

2. Flexibilidade na Verificação

Destaca a flexibilidade de cada estrutura na personalização do seu mecanismo de verificação - especificamente, se os emissores de tokens podem escolher entre várias opções ou estão limitados às configurações padrão.

3. Esquemas de Verificação Pré-Construídos Notáveis

Esquemas pré-construídos são mecanismos de verificação prontos para uso que os emissores de token podem usar para verificação de mensagens, simplificando a implantação. Um framework com uma seleção mais ampla de opções pré-construídas e confiáveis é geralmente um sinal positivo.

Embora alguns frameworks ofereçam mais esquemas de verificação do que outros, é essencial.avaliá-los com base no seu espectro de segurança, que pode variar de um único validador a conjuntos abrangentes de validadores.

Por exemplo, os OFTs oferecem opções DVN que são validadores únicos, juntamente com escolhas mais robustas como CCIP ou Axelar, que usam conjuntos completos de validadores. Da mesma forma, o Token Warp oferece ISMs como o ISM Multisig que inclui validadores geridos pela comunidade Hyperlane e, ao mesmo tempo, existem opções como o ISM de Agregação que permite que as equipas combinem segurança de vários ISMs.

Além disso, muitos desses esquemas de verificação podem ainda não ser amplamente adotados ou testados minuciosamente em cenários do mundo real. Assim, as equipes devem avaliar cuidadosamente a qualidade dos esquemas de verificação disponíveis e escolher aquele que se alinha com seu nível desejado de segurança. Recomendamos fortemente aproveitar as opções disponíveis para construir uma configuração segura e resiliente para a verificação de token. Em um futuro artigo de pesquisa, iremos aprofundar nas propriedades de segurança dos diferentes esquemas de verificação oferecidos por cada estrutura de token.

4. Esquema de Verificação Padrão

Indica se o framework fornece um mecanismo de verificação padrão. Isso é importante porque a maioria das equipes geralmente opta por opções padrão por conveniência. Se um emissor de token optar pela opção padrão, é crucial avaliar sua segurança, bem como considerar o uso dos recursos de personalização oferecidos para aprimorar a segurança da configuração.

5. Participação na Verificação do App

Destaca se as equipas têm a opção de participar no processo de verificação, adicionando uma camada extra de segurança ou permitindo-lhes assumir o controlo da sua segurança. Isto é importante porque permite às equipas reforçar a segurança ao incorporar a sua própria configuração de verificação ao lado dos mecanismos existentes. Desta forma, se outros métodos de verificação falharem, podem confiar nos seus próprios salvaguardas para prevenir potenciais problemas.

Por exemplo, equipes como StarGate, Tapioca, BitGo, Cluster e Abracadabra executam suas próprias DVNs na LayerZero, mostrando como outras equipes podem aproveitar as personalizações disponíveis.

Mais equipas deviam aproveitar esta camada adicional de segurança, apesar do esforço extra necessário. Quando implementado de forma eficaz, esta funcionalidade pode ser crucial na prevenção de problemas graves durante falhas críticas.

6. Resistência à censura

Define se e como as mensagens podem ser censuradas, potencialmente desativando aplicações e causando problemas de funcionamento para as equipas. Na maioria dos casos, mesmo que as aplicações sejam censuradas, podem mudar para diferentes mecanismos de verificação ou transmissores dentro do mesmo quadro. No entanto, isso requer esforço adicional e pode não ser uma solução prática para problemas a curto prazo.

7. Open-Sourceness

Os códigos abertos permitem que os desenvolvedores auditem as funcionalidades de segurança e configuração geral de um framework, garantindo transparência sobre o código que está sendo executado.

Taxas

Esta tabela compara as estruturas de taxas de vários frameworks de token, focando em como cada um lida com os custos das operações de protocolo, mensagens e quaisquer taxas adicionais. É importante notar que todos os frameworks permitem a adição de taxas personalizadas específicas do aplicativo no nível do aplicativo. Além disso, há um custo associado ao processo de verificação e transferência, incluindo as taxas pagas a relayers, transmissores ou entidades similares, em todos os frameworks.

Atualmente, a maioria das taxas está associada à verificação e transmissão de mensagens. Como mencionado anteriormente, todos os frameworks de token fornecem a opção de usar vários mecanismos para verificar mensagens. Embora cada esquema de verificação adicional aprimore a segurança do sistema, também aumenta as taxas e os custos para os usuários.

1. Taxas de Protocolo

Isso refere-se às taxas de nível de protocolo que cada estrutura cobra pela execução de transferências ou outras operações.

A presença de um interruptor de taxa governado pela DAO significa que os emissores de tokens podem precisar pagar taxas adicionais aos protocolos de interoperabilidade por trás das estruturas de tokens (por exemplo, LayerZero para OFTs ou Hyperlane para Warp Token). Isso introduz uma dependência na governança DAO, pois quaisquer alterações no interruptor de taxa afetam diretamente os tokens emitidos por meio dessas estruturas, tornando-os sujeitos às decisões da DAO sobre estruturas de taxa.

Contratos Inteligentes

Esta tabela destaca as principais propriedades dos contratos inteligentes de cada estrutura, destacando seus diferentes graus de flexibilidade, segurança e personalização, com foco no histórico de implantação, auditorias de segurança, recompensas oferecidas e personalizações notáveis para controle granular.

É importante notar que todos os frameworks permitem que os aplicativos definam limites de taxa e listas negras, recursos de segurança cruciais que, quando usados de forma eficaz, podem evitar perdas financeiras significativasAlém disso, cada estrutura oferece a flexibilidade de implantar contratos inteligentes como imutáveis ou atualizáveis, dependendo das necessidades específicas do aplicativo.

1. Implementado Desde

Este campo mostra quando os smart contracts de cada framework foram implantados. Isso proporciona uma visão de quanto tempo o framework está operacional.

2. Auditorias

O número de auditorias é uma medida crucial de segurança. As auditorias validam a integridade dos contratos inteligentes de uma estrutura, identificando vulnerabilidades ou problemas que possam comprometer o sistema.

3. Recompensas

As recompensas refletem os incentivos financeiros oferecidos pelos frameworks para incentivar pesquisadores de segurança externos a descobrir e relatar vulnerabilidades.

4. Característica Notável para Controlo Granular

As estruturas de contratos inteligentes permitem que as aplicações implementem uma variedade de recursos de segurança personalizáveis, dependendo das suas necessidades específicas. Este campo destaca alguns recursos de segurança chave que cada estrutura oferece para garantir a segurança.

Adoção & Expansão

Cada estrutura traz recursos exclusivos e tem visto diferentes níveis de envolvimento de desenvolvedores, protocolos e plataformas, dependendo de seu foco técnico, integrações e garantias de segurança.

1.Principais contribuidores

Esta seção destaca as várias equipes ativamente envolvidas na construção e manutenção de cada estrutura. Um conjunto diversificado de colaboradores, além da equipe de desenvolvimento original, é um indicador positivo de vários fatores: (1) uma demanda mais ampla pela estrutura e (2) a acessibilidade e facilidade de uso da estrutura, seja de forma permissiva ou por meio de colaboração geral.

2.Adopção

A adoção reflete o nível de uso e tração de cada estrutura, medido pelo número de tokens implantados e o valor total garantido. Isso fornece uma visão de quão amplamente a estrutura foi adotada por desenvolvedores e protocolos, bem como sua confiabilidade na segurança de ativos.

3.Equipas Notáveis

Esta seção destaca as principais equipes e protocolos que adotaram cada estrutura, refletindo sua confiança na indústria e apelo geral.

4.Cobertura VM

A cobertura de VM refere-se à gama de máquinas virtuais suportadas por cada estrutura. Um maior número de VMs oferece mais flexibilidade e compatibilidade em diferentes ambientes de blockchain. Isso proporciona às apps e emissores de token uma maior variedade em termos de comunidades diversas às quais podem aceder.

5.Cadeias implantadas em

Este campo reflete o número de cadeias em que cada estrutura é implantada, ou seja, o número de cadeias que cada aplicativo ou emissor de token poderia suportar se decidissem usar uma estrutura específica. Isso está diretamente relacionado ao número de mercados e ecossistemas DeFi aos quais os aplicativos podem acessar. Implantação de cadeia mais alta significa acesso mais amplo à liquidez.

Além disso, embora a capacidade de expandir um framework sem permissão em diferentes cadeias tenha grande potencial, também pode ser desafiador se os desenvolvedores precisarem construir e manter a infraestrutura crítica por si mesmos. Para alguns, como equipes que buscam estabelecer suporte de ponte para uma nova cadeia, esse esforço pode valer a pena. Mas para emissores de token que apenas desejam adicionar outra cadeia ao alcance de seu token, pode parecer desnecessariamente complexo e intensivo em recursos.

6. Diferenciais exclusivos

Cada estrutura traz diferenciadores únicos, muitas vezes na forma de características especiais, ferramentas ou integrações que a distinguem das outras. Normalmente, esses diferenciadores atraem desenvolvedores e protocolos em busca de funcionalidades específicas, facilidade de uso ou simplesmente mais distribuição para seu token.

Experiência do desenvolvedor

Aviso Legal: Esta seção reflete as percepções de @SlavaOnChain (Chefe de DevRel na LI.FI) e discussões com desenvolvedores familiarizados com vários frameworks. As experiências do desenvolvedor podem variar com base no histórico e no caso de uso.

1. Facilidade de Integração

Refere-se a quão direto foi implantar tokens usando o framework com base na experiência de primeira vez sem suporte da equipe.

2.Documentação

Avalia quão bem os guias, exemplos e referências do framework apoiam os desenvolvedores na compreensão e utilização da plataforma.

3. Ferramentas de Desenvolvedor

Considera o conjunto de bibliotecas, SDKs e utilitários que facilitam a construção, teste e implementação de tokens usando o framework.

Principais conclusões

  1. Personalização e mecanismos de verificação — Todos os frameworks oferecem personalização nos mecanismos de verificação, marcando uma nova tendência em protocolos de interoperabilidade. A discussão no fórum de governança da Lido DAO sobre wstETH foi um momento crucial que destacou a demanda por esse recurso.
  2. Práticas de Segurança - Recursos como limites de taxa, listas de permissões/listas negras e permitir que os emissores de tokens participem na verificação de mensagens e configuração de segurança através de políticas e funções personalizadas tornaram-se práticas padrão em estruturas, indicando uma direção positiva para a segurança no espaço de interoperabilidade.
  3. Desafios na adoção além das configurações padrão - Embora os mecanismos de verificação personalizados sejam benéficos, a adoção além das configurações padrão ainda é baixa, exigindo uma melhor educação sobre opções de segurança. É fundamental focar em garantir que os esquemas de verificação padrão sejam altamente seguros, pois são os mais comumente usados.
  4. Mecanismos de verificação — O conjunto de validadores da Axelar e a rede Wormhole's Guardian são mecanismos de verificação amplamente adotados, oferecidos em todas as estruturas.

B. Estruturas Líderes de Token

  1. OFT pela LayerZero - lidera na adoção, tanto para tokens implantados como para o valor total garantido. Foram os primeiros a lançar estruturas de token com OFT (V1) em 2022 e continuaram a fortalecer a sua posição, com importantes ativos como o WBTC recentemente adotando o framework OFT. Também oferecem amplo suporte para a maioria das cadeias e recursos abrangentes para desenvolvedores.
  2. Token Warp pela Hyperlane - A equipe está fortemente focada em tornar a estrutura e as ferramentas de desenvolvedor amigáveis para operações sem permissão. Isso é demonstrado pelas múltiplas implementações de VM construídas e mantidas por equipes externas, mostrando a facilidade de trabalhar com a estrutura de maneira sem permissão.
  3. NTT by Wormhole - Tem ganho rapidamente adoção com tokens de alto valor implantados em várias cadeias e oferece várias propriedades únicas em seu design, como a ausência de uma taxa de protocolo ao nível do switch. É uma opção popular para equipes que procuram expandir seus tokens para o ecossistema Solana ou tokens Solana para o ecossistema EVM.
  4. ITS by Axelar - Com um TVL superior a$400M, Axelar está entre as 25 principais cadeias de PoS. A estrutura ITS é um importante motor de crescimento, contribuindo tanto para o TVL como para o volume de mensagens enviadas através da rede Axelar.
  5. Estrutura xERC20 - A única estrutura totalmente independente de ponte, ao contrário de outras que são mais como produtos. Muitos protocolos de interoperabilidade que não possuem suas próprias estruturas incentivam as equipes a usar o xERC20 para implantar tokens, alguns oferecendo modelos pré-criados para integração.
  6. Diferenças na estrutura de taxas — xERC20 e NTT são duas estruturas que não têm uma mudança de taxa de nível de protocolo.

Considerações Finais

As estruturas de Token estão em ascensão e podem acabar por mudar tudo sobre como o valor se move num mundo multi-cadeias. Atualmente, a transferência de ativos entre cadeias frequentemente requer pools de liquidez ou solucionadores, mas os frameworks de token eliminam essas necessidades. Em vez disso, os ativos podem ser criados diretamente na cadeia desejada por meio de protocolos de interoperabilidade.

Na verdade, os frameworks de token podem ser o golpe de misericórdia para ativos envelopados. A liquidez não precisaria mais ser fragmentada em várias correntes. Você poderia criar ativos fungíveis em qualquer corrente e eles seriam negociáveis ​​em várias correntes pelo custo do gás. Já estamos vendo sinais dessa mudança. A Circle lançou o CCTP para contornar o problema do token envelopado para USDC e muitas equipes grandes e tokens de alto valor estão adotando frameworks de token. Isso é um sinal de que as coisas estão acelerando.

No entanto, existem preocupações válidas em relação ao risco de contágio de terceiros — se os protocolos de interoperabilidade falharem, eles podem impactar todos os projetos construídos sobre eles. Apesar desses riscos, a adoção continua a crescer.

Outro ponto de vista: em um futuro abstraído em cadeia, as estruturas de token não serão mais importantes porque os solucionadores trocarão tokens nativos por usuários nos bastidores. E embora haja alguma verdade nisso – os usuários não precisarão pensar em tokens – ele perde um ângulo crítico. E os próprios solucionadores? Para eles, as estruturas de token podem ser realmente úteis. Eles resolvem dores de cabeça de estoque e reequilíbrio porque não precisam de liquidez para se mover entre cadeias. É por isso que os solucionadores gostam de usar estruturas como CCTP para mover USDC - é barato, eficiente e perfeito para reequilíbrio entre cadeias.

Como tudo isso se molda ainda é uma incógnita. Talvez precisemos apenas de estruturas de token para um pequeno grupo de cadeias marginais ou talvez elas se tornem o padrão para implantar tokens em criptomoedas. O que sabemos hoje é que a adoção de estruturas de interoperabilidade está crescendo, assim como a concorrência. O problema deste crescimento? Fragmentação. Estruturas concorrentes vão dividir ativos e liquidez, e não veremos uma solução única. Os incentivos simplesmente não permitem.

Aviso Legal:

  1. Este artigo foi reproduzido a partir de [LI.FI]. Todos os direitos autorais pertencem ao autor original [Arjun Chand]. Se houver objeções a esta reimpressão, contacte o Gate Learn equipe, e eles vão lidar com isso prontamente.
  2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
  3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.

Comparando Estruturas de Token

AvançadoOct 09, 2024
Neste artigo, vamos comparar os principais frameworks de token oferecidos por diferentes protocolos de interoperabilidade. O objetivo é avaliar suas características únicas, pontos fortes e compensações para ajudar as equipes a escolher a melhor solução para emitir tokens nativamente multi-cadeia.
Comparando Estruturas de Token

Introdução

Emitir um token costumava ser simples: você o implantaria no Ethereum, onde toda a ação estava - usuários, negociantes, capital e liquidez. Hoje, o cenário é muito mais complexo. A liquidez está espalhada por Bitcoin, Ethereum, L2s, Solana e outras cadeias. Então, onde você deve emitir seu token? Não há uma resposta clara.

Mas e se você não tivesse que escolher apenas uma cadeia? Imagine um token que funciona em todos os lugares, fluindo perfeitamente por toda a economia criptográfica.

Graças aprotocolos de interoperabilidade (também conhecidas como pontes), agora é possível emitir tokens com um mercado unificado que abrange várias cadeias. Isso cria liquidez global sem fronteiras, simplificando as operações para emissores de tokens: mais liquidez, maior adoção e efeitos de rede mais fortes - sem as dores de cabeça da fragmentação. Essencialmente, é como ter uma conta bancária global que funciona em todos os lugares, integrada em todos os ecossistemas DeFi.

Neste artigo, vamos comparar os principais frameworks de token oferecidos por diferentes protocolos de interoperabilidade. O objetivo é avaliar suas características únicas, pontos fortes e compensações para ajudar as equipes a escolher a melhor solução para emitir tokens nativamente multi-chain.

Vamos explorar os seguintes frameworks:

  • Serviço de Token Interchain (ITS) da Axelar
  • Transferências do Token Nativo do Wormhole (NTT)
  • Token Fungível Omnichain da LayerZero (OFT)
  • Token de Warp da Hyperlane
  • xERC20 (EIP 7281: Tokens Transponíveis Soberanos)

Vamos mergulhar.

Como funcionam os frameworks de Token

As estruturas de token operam de duas maneiras principais, dependendo se você está tornando um token existente multi-cadeia ou lançando um token nativamente multi-cadeia desde o início.

Burn-and-Mint: Para Tokens Nativos de Múltiplas Cadeias

Quando um Token é emitido nativamente em várias cadeias a partir do Dia 1, o seu fornecimento é distribuído por essas cadeias. Quando os Tokens são movidos entre cadeias, eles são queimados na cadeia de origem e cunhados na cadeia de destino, garantindo que o fornecimento total permaneça constante.

Pense nisso como um sistema de contabilidade (como muitas equipes de interoperabilidade explicaram). Aqui está um exemplo: considere o Token X com um fornecimento total de 1000 tokens, distribuídos com base na demanda em cinco cadeias:

  • Cadeia A: 400 tokens
  • Chain B: 200 tokens
  • Chain C: 200 tokens
  • Chain D: 100 tokens
  • Chain E: 100 tokens

Se um usuário transferir 50 tokens da Cadeia E para a Cadeia A, esses tokens serão gravados na Cadeia E e cunhados na Cadeia A. A distribuição atualizada seria:

  • Chain A: 450 tokens
  • Cadeia B: 200 tokens
  • Chain C: 200 tokens
  • Chain D: 100 tokens
  • Chain E: 50 tokens

Este processo garante que o fornecimento total permaneça em 1000 tokens, facilitando transferências sem falhas entre cadeias.

Travar e Criar: Para Tokens Existente

Para tokens já existentes que foram inicialmente implantados em uma única cadeia, o processo é ligeiramente diferente. Todo o fornecimento existe em uma única cadeia e, ao transferir para outra cadeia, parte do fornecimento é bloqueado em um contrato inteligente na cadeia de origem, enquanto uma quantidade equivalente é criada na cadeia de destino.

Este método é semelhante à forma como os tokens envolvidos operam. Tokens bloqueados na Chain A podem então ter uma versão envolvida cunhada na Chain B. No entanto, agora estes tokens também podem mover-se da Chain B para a Chain C usando o método de queimar-cunhar, sem necessidade de serem bloqueados em várias chains. O fornecimento original permanece na Chain A, garantindo que as transferências entre as chains simplesmente envolvam a verificação de que os tokens queimados correspondem aos cunhados.

Por que os Frameworks de Token são Importantes

Aqui está o motivo pelo qual ter um token negociável em um mercado unificado que abrange várias cadeias beneficia as equipas:

  • Liquidez - Um único mercado atrai mais traders, aumentando a liquidez.
  • Consciência da marca — Os Tokens tornam-se acessíveis em vários ecossistemas DeFi, aumentando a demanda e o reconhecimento da marca.
  • Simplicidade — A gestão de Token torna-se mais fácil, reduzindo a complexidade.
  • Redundância - Se uma cadeia falhar, os tokens ainda podem operar em outras, fornecendo uma rede de segurança.
  • Expansão de mercado — O token pode ser implantado em várias cadeias mais rapidamente, impulsionando a adoção. Além disso, ecossistemas interligados significam mais espaço para experimentação em DeFi.
  • Efeitos de rede - Colaboração com outros projetos aumenta a adoção e o valor.

ConsiderarProtocolo de Transferência Cross-Chain da Circle (CCTP)Ao lançar CCTP, a Circle permitiu que o USDC fosse negociado de forma transparente em todas as cadeias suportadas, abordando questões-chave:

  • Sem liquidez fragmentada - Antes, você tinha diferentes versões de USDC em cada cadeia, o que levava à ineficiência. Agora, o USDC é o mesmo em todas as cadeias.
  • Expansão do mercado - A implementação do USDC em várias cadeias dá-lhes acesso a mais utilizadores e mercados.
  • Eficiência de capital — Os usuários podem fazer a ponte de grandes quantidades de USDC sem necessidade de pools de liquidez ou wrapping.
  • Taxas mínimas - As transferências custam pouco além das taxas de gás.
  • Sem deslizamento - As transferências são diretas e eliminam o risco de deslizamento.

A característica única do Circle para o USDC deve-se à sua ponte personalizada, CCTP, um luxo que a maioria dos projetos não possui. Aqui é onde entram em jogo os frameworks de token mantidos por protocolos de interoperabilidade. Estes frameworks fornecem uma solução semelhante ao que a CCTP oferece para o USDC, mas para qualquer token. Ao emitir um token através destes frameworks, os projetos podem criar um mercado unificado em várias cadeias suportadas, permitindo transferências fáceis utilizando mecanismos de queima/bloqueio e mint.

Comparação de Estruturas de Token

Agora que entendemos como funcionam as estruturas de token e seus benefícios, vamos comparar as várias soluções disponíveis no mercado para equipes que buscam emitir seus tokens.

Segurança

Aqui está uma explicação dos aspectos críticos de segurança abordados na tabela:

1. Mecanismo de verificação

O mecanismo de verificação está no cerne de como as transferências são validadas através das cadeias. Refere-se à forma como as mensagens são verificadas e ao tipo de configuração em termos de mecanismos de verificação que cada estrutura fornece - seja uma opção única, um sistema modular com várias opções ou um design flexível compatível com qualquer ponte - permitindo que os emissores de tokens selecionem a solução mais adequada com base em seus requisitos de segurança.

Embora os mecanismos de verificação personalizados ofereçam benefícios, são as configurações padrão quepermanecer o mais amplamente utilizado. Portanto, é importante focar na segurança dos esquemas de verificação padrão. Recomenda-se que as equipes usem esquemas de verificação adicionais além dos padrões para aprimorar sua configuração de segurança.

Quando se trata de vivacidade, confiar em múltiplos esquemas de verificação tem tanto benefícios como inconvenientes. Do lado positivo, há uma melhor tolerância a falhas: se um fornecedor enfrentar tempo de inatividade, outros podem garantir operações contínuas, melhorando a fiabilidade do sistema. No entanto, isso também aumenta a complexidade do sistema. Cada esquema adicional introduz um potencial ponto de falha, aumentando o risco de interrupções operacionais.

2. Flexibilidade na Verificação

Destaca a flexibilidade de cada estrutura na personalização do seu mecanismo de verificação - especificamente, se os emissores de tokens podem escolher entre várias opções ou estão limitados às configurações padrão.

3. Esquemas de Verificação Pré-Construídos Notáveis

Esquemas pré-construídos são mecanismos de verificação prontos para uso que os emissores de token podem usar para verificação de mensagens, simplificando a implantação. Um framework com uma seleção mais ampla de opções pré-construídas e confiáveis é geralmente um sinal positivo.

Embora alguns frameworks ofereçam mais esquemas de verificação do que outros, é essencial.avaliá-los com base no seu espectro de segurança, que pode variar de um único validador a conjuntos abrangentes de validadores.

Por exemplo, os OFTs oferecem opções DVN que são validadores únicos, juntamente com escolhas mais robustas como CCIP ou Axelar, que usam conjuntos completos de validadores. Da mesma forma, o Token Warp oferece ISMs como o ISM Multisig que inclui validadores geridos pela comunidade Hyperlane e, ao mesmo tempo, existem opções como o ISM de Agregação que permite que as equipas combinem segurança de vários ISMs.

Além disso, muitos desses esquemas de verificação podem ainda não ser amplamente adotados ou testados minuciosamente em cenários do mundo real. Assim, as equipes devem avaliar cuidadosamente a qualidade dos esquemas de verificação disponíveis e escolher aquele que se alinha com seu nível desejado de segurança. Recomendamos fortemente aproveitar as opções disponíveis para construir uma configuração segura e resiliente para a verificação de token. Em um futuro artigo de pesquisa, iremos aprofundar nas propriedades de segurança dos diferentes esquemas de verificação oferecidos por cada estrutura de token.

4. Esquema de Verificação Padrão

Indica se o framework fornece um mecanismo de verificação padrão. Isso é importante porque a maioria das equipes geralmente opta por opções padrão por conveniência. Se um emissor de token optar pela opção padrão, é crucial avaliar sua segurança, bem como considerar o uso dos recursos de personalização oferecidos para aprimorar a segurança da configuração.

5. Participação na Verificação do App

Destaca se as equipas têm a opção de participar no processo de verificação, adicionando uma camada extra de segurança ou permitindo-lhes assumir o controlo da sua segurança. Isto é importante porque permite às equipas reforçar a segurança ao incorporar a sua própria configuração de verificação ao lado dos mecanismos existentes. Desta forma, se outros métodos de verificação falharem, podem confiar nos seus próprios salvaguardas para prevenir potenciais problemas.

Por exemplo, equipes como StarGate, Tapioca, BitGo, Cluster e Abracadabra executam suas próprias DVNs na LayerZero, mostrando como outras equipes podem aproveitar as personalizações disponíveis.

Mais equipas deviam aproveitar esta camada adicional de segurança, apesar do esforço extra necessário. Quando implementado de forma eficaz, esta funcionalidade pode ser crucial na prevenção de problemas graves durante falhas críticas.

6. Resistência à censura

Define se e como as mensagens podem ser censuradas, potencialmente desativando aplicações e causando problemas de funcionamento para as equipas. Na maioria dos casos, mesmo que as aplicações sejam censuradas, podem mudar para diferentes mecanismos de verificação ou transmissores dentro do mesmo quadro. No entanto, isso requer esforço adicional e pode não ser uma solução prática para problemas a curto prazo.

7. Open-Sourceness

Os códigos abertos permitem que os desenvolvedores auditem as funcionalidades de segurança e configuração geral de um framework, garantindo transparência sobre o código que está sendo executado.

Taxas

Esta tabela compara as estruturas de taxas de vários frameworks de token, focando em como cada um lida com os custos das operações de protocolo, mensagens e quaisquer taxas adicionais. É importante notar que todos os frameworks permitem a adição de taxas personalizadas específicas do aplicativo no nível do aplicativo. Além disso, há um custo associado ao processo de verificação e transferência, incluindo as taxas pagas a relayers, transmissores ou entidades similares, em todos os frameworks.

Atualmente, a maioria das taxas está associada à verificação e transmissão de mensagens. Como mencionado anteriormente, todos os frameworks de token fornecem a opção de usar vários mecanismos para verificar mensagens. Embora cada esquema de verificação adicional aprimore a segurança do sistema, também aumenta as taxas e os custos para os usuários.

1. Taxas de Protocolo

Isso refere-se às taxas de nível de protocolo que cada estrutura cobra pela execução de transferências ou outras operações.

A presença de um interruptor de taxa governado pela DAO significa que os emissores de tokens podem precisar pagar taxas adicionais aos protocolos de interoperabilidade por trás das estruturas de tokens (por exemplo, LayerZero para OFTs ou Hyperlane para Warp Token). Isso introduz uma dependência na governança DAO, pois quaisquer alterações no interruptor de taxa afetam diretamente os tokens emitidos por meio dessas estruturas, tornando-os sujeitos às decisões da DAO sobre estruturas de taxa.

Contratos Inteligentes

Esta tabela destaca as principais propriedades dos contratos inteligentes de cada estrutura, destacando seus diferentes graus de flexibilidade, segurança e personalização, com foco no histórico de implantação, auditorias de segurança, recompensas oferecidas e personalizações notáveis para controle granular.

É importante notar que todos os frameworks permitem que os aplicativos definam limites de taxa e listas negras, recursos de segurança cruciais que, quando usados de forma eficaz, podem evitar perdas financeiras significativasAlém disso, cada estrutura oferece a flexibilidade de implantar contratos inteligentes como imutáveis ou atualizáveis, dependendo das necessidades específicas do aplicativo.

1. Implementado Desde

Este campo mostra quando os smart contracts de cada framework foram implantados. Isso proporciona uma visão de quanto tempo o framework está operacional.

2. Auditorias

O número de auditorias é uma medida crucial de segurança. As auditorias validam a integridade dos contratos inteligentes de uma estrutura, identificando vulnerabilidades ou problemas que possam comprometer o sistema.

3. Recompensas

As recompensas refletem os incentivos financeiros oferecidos pelos frameworks para incentivar pesquisadores de segurança externos a descobrir e relatar vulnerabilidades.

4. Característica Notável para Controlo Granular

As estruturas de contratos inteligentes permitem que as aplicações implementem uma variedade de recursos de segurança personalizáveis, dependendo das suas necessidades específicas. Este campo destaca alguns recursos de segurança chave que cada estrutura oferece para garantir a segurança.

Adoção & Expansão

Cada estrutura traz recursos exclusivos e tem visto diferentes níveis de envolvimento de desenvolvedores, protocolos e plataformas, dependendo de seu foco técnico, integrações e garantias de segurança.

1.Principais contribuidores

Esta seção destaca as várias equipes ativamente envolvidas na construção e manutenção de cada estrutura. Um conjunto diversificado de colaboradores, além da equipe de desenvolvimento original, é um indicador positivo de vários fatores: (1) uma demanda mais ampla pela estrutura e (2) a acessibilidade e facilidade de uso da estrutura, seja de forma permissiva ou por meio de colaboração geral.

2.Adopção

A adoção reflete o nível de uso e tração de cada estrutura, medido pelo número de tokens implantados e o valor total garantido. Isso fornece uma visão de quão amplamente a estrutura foi adotada por desenvolvedores e protocolos, bem como sua confiabilidade na segurança de ativos.

3.Equipas Notáveis

Esta seção destaca as principais equipes e protocolos que adotaram cada estrutura, refletindo sua confiança na indústria e apelo geral.

4.Cobertura VM

A cobertura de VM refere-se à gama de máquinas virtuais suportadas por cada estrutura. Um maior número de VMs oferece mais flexibilidade e compatibilidade em diferentes ambientes de blockchain. Isso proporciona às apps e emissores de token uma maior variedade em termos de comunidades diversas às quais podem aceder.

5.Cadeias implantadas em

Este campo reflete o número de cadeias em que cada estrutura é implantada, ou seja, o número de cadeias que cada aplicativo ou emissor de token poderia suportar se decidissem usar uma estrutura específica. Isso está diretamente relacionado ao número de mercados e ecossistemas DeFi aos quais os aplicativos podem acessar. Implantação de cadeia mais alta significa acesso mais amplo à liquidez.

Além disso, embora a capacidade de expandir um framework sem permissão em diferentes cadeias tenha grande potencial, também pode ser desafiador se os desenvolvedores precisarem construir e manter a infraestrutura crítica por si mesmos. Para alguns, como equipes que buscam estabelecer suporte de ponte para uma nova cadeia, esse esforço pode valer a pena. Mas para emissores de token que apenas desejam adicionar outra cadeia ao alcance de seu token, pode parecer desnecessariamente complexo e intensivo em recursos.

6. Diferenciais exclusivos

Cada estrutura traz diferenciadores únicos, muitas vezes na forma de características especiais, ferramentas ou integrações que a distinguem das outras. Normalmente, esses diferenciadores atraem desenvolvedores e protocolos em busca de funcionalidades específicas, facilidade de uso ou simplesmente mais distribuição para seu token.

Experiência do desenvolvedor

Aviso Legal: Esta seção reflete as percepções de @SlavaOnChain (Chefe de DevRel na LI.FI) e discussões com desenvolvedores familiarizados com vários frameworks. As experiências do desenvolvedor podem variar com base no histórico e no caso de uso.

1. Facilidade de Integração

Refere-se a quão direto foi implantar tokens usando o framework com base na experiência de primeira vez sem suporte da equipe.

2.Documentação

Avalia quão bem os guias, exemplos e referências do framework apoiam os desenvolvedores na compreensão e utilização da plataforma.

3. Ferramentas de Desenvolvedor

Considera o conjunto de bibliotecas, SDKs e utilitários que facilitam a construção, teste e implementação de tokens usando o framework.

Principais conclusões

  1. Personalização e mecanismos de verificação — Todos os frameworks oferecem personalização nos mecanismos de verificação, marcando uma nova tendência em protocolos de interoperabilidade. A discussão no fórum de governança da Lido DAO sobre wstETH foi um momento crucial que destacou a demanda por esse recurso.
  2. Práticas de Segurança - Recursos como limites de taxa, listas de permissões/listas negras e permitir que os emissores de tokens participem na verificação de mensagens e configuração de segurança através de políticas e funções personalizadas tornaram-se práticas padrão em estruturas, indicando uma direção positiva para a segurança no espaço de interoperabilidade.
  3. Desafios na adoção além das configurações padrão - Embora os mecanismos de verificação personalizados sejam benéficos, a adoção além das configurações padrão ainda é baixa, exigindo uma melhor educação sobre opções de segurança. É fundamental focar em garantir que os esquemas de verificação padrão sejam altamente seguros, pois são os mais comumente usados.
  4. Mecanismos de verificação — O conjunto de validadores da Axelar e a rede Wormhole's Guardian são mecanismos de verificação amplamente adotados, oferecidos em todas as estruturas.

B. Estruturas Líderes de Token

  1. OFT pela LayerZero - lidera na adoção, tanto para tokens implantados como para o valor total garantido. Foram os primeiros a lançar estruturas de token com OFT (V1) em 2022 e continuaram a fortalecer a sua posição, com importantes ativos como o WBTC recentemente adotando o framework OFT. Também oferecem amplo suporte para a maioria das cadeias e recursos abrangentes para desenvolvedores.
  2. Token Warp pela Hyperlane - A equipe está fortemente focada em tornar a estrutura e as ferramentas de desenvolvedor amigáveis para operações sem permissão. Isso é demonstrado pelas múltiplas implementações de VM construídas e mantidas por equipes externas, mostrando a facilidade de trabalhar com a estrutura de maneira sem permissão.
  3. NTT by Wormhole - Tem ganho rapidamente adoção com tokens de alto valor implantados em várias cadeias e oferece várias propriedades únicas em seu design, como a ausência de uma taxa de protocolo ao nível do switch. É uma opção popular para equipes que procuram expandir seus tokens para o ecossistema Solana ou tokens Solana para o ecossistema EVM.
  4. ITS by Axelar - Com um TVL superior a$400M, Axelar está entre as 25 principais cadeias de PoS. A estrutura ITS é um importante motor de crescimento, contribuindo tanto para o TVL como para o volume de mensagens enviadas através da rede Axelar.
  5. Estrutura xERC20 - A única estrutura totalmente independente de ponte, ao contrário de outras que são mais como produtos. Muitos protocolos de interoperabilidade que não possuem suas próprias estruturas incentivam as equipes a usar o xERC20 para implantar tokens, alguns oferecendo modelos pré-criados para integração.
  6. Diferenças na estrutura de taxas — xERC20 e NTT são duas estruturas que não têm uma mudança de taxa de nível de protocolo.

Considerações Finais

As estruturas de Token estão em ascensão e podem acabar por mudar tudo sobre como o valor se move num mundo multi-cadeias. Atualmente, a transferência de ativos entre cadeias frequentemente requer pools de liquidez ou solucionadores, mas os frameworks de token eliminam essas necessidades. Em vez disso, os ativos podem ser criados diretamente na cadeia desejada por meio de protocolos de interoperabilidade.

Na verdade, os frameworks de token podem ser o golpe de misericórdia para ativos envelopados. A liquidez não precisaria mais ser fragmentada em várias correntes. Você poderia criar ativos fungíveis em qualquer corrente e eles seriam negociáveis ​​em várias correntes pelo custo do gás. Já estamos vendo sinais dessa mudança. A Circle lançou o CCTP para contornar o problema do token envelopado para USDC e muitas equipes grandes e tokens de alto valor estão adotando frameworks de token. Isso é um sinal de que as coisas estão acelerando.

No entanto, existem preocupações válidas em relação ao risco de contágio de terceiros — se os protocolos de interoperabilidade falharem, eles podem impactar todos os projetos construídos sobre eles. Apesar desses riscos, a adoção continua a crescer.

Outro ponto de vista: em um futuro abstraído em cadeia, as estruturas de token não serão mais importantes porque os solucionadores trocarão tokens nativos por usuários nos bastidores. E embora haja alguma verdade nisso – os usuários não precisarão pensar em tokens – ele perde um ângulo crítico. E os próprios solucionadores? Para eles, as estruturas de token podem ser realmente úteis. Eles resolvem dores de cabeça de estoque e reequilíbrio porque não precisam de liquidez para se mover entre cadeias. É por isso que os solucionadores gostam de usar estruturas como CCTP para mover USDC - é barato, eficiente e perfeito para reequilíbrio entre cadeias.

Como tudo isso se molda ainda é uma incógnita. Talvez precisemos apenas de estruturas de token para um pequeno grupo de cadeias marginais ou talvez elas se tornem o padrão para implantar tokens em criptomoedas. O que sabemos hoje é que a adoção de estruturas de interoperabilidade está crescendo, assim como a concorrência. O problema deste crescimento? Fragmentação. Estruturas concorrentes vão dividir ativos e liquidez, e não veremos uma solução única. Os incentivos simplesmente não permitem.

Aviso Legal:

  1. Este artigo foi reproduzido a partir de [LI.FI]. Todos os direitos autorais pertencem ao autor original [Arjun Chand]. Se houver objeções a esta reimpressão, contacte o Gate Learn equipe, e eles vão lidar com isso prontamente.
  2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
  3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.
Comece agora
Registe-se e ganhe um cupão de
100 USD
!