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:
Vamos mergulhar.
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.
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:
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:
Este processo garante que o fornecimento total permaneça em 1000 tokens, facilitando transferências sem falhas entre cadeias.
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.
Aqui está o motivo pelo qual ter um token negociável em um mercado unificado que abrange várias cadeias beneficia as equipas:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
Vamos mergulhar.
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.
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:
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:
Este processo garante que o fornecimento total permaneça em 1000 tokens, facilitando transferências sem falhas entre cadeias.
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.
Aqui está o motivo pelo qual ter um token negociável em um mercado unificado que abrange várias cadeias beneficia as equipas:
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:
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.
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.
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.
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.
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.
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.
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.
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.