Ligação das cadeias de EVM personalizadas à liquidez Tron | Entrevista com Andrew Nalichaev

29 de abril de 2026

Resumir com IA

Nesta conversa, Andrew dá uma olhada mais de perto no que significa conectar uma cadeia EVM personalizada à liquidez do Tron. Ele percorre a segurança da ponte, vulnerabilidades de casos extremos, os limites das auditorias e as compensações por trás dos modelos LP, lock-and-mint, baseados em intenção e híbridos, com foco no que realmente quebra na produção e por quê.

Se estiver a trabalhar com cadeias personalizadas, interoperabilidade ou encaminhamento de liquidez, esta é uma análise prática das decisões subjacentes à infraestrutura entre cadeias.

Texto da entrevista

Explore a exploração do CrossCurve em fevereiro de 2026. O que é que falhou exatamente e como é que incidentes como este devem mudar a forma como pensamos sobre as pontes entre cadeias?

Penso que é uma pergunta brilhante, porque temos uma parceria com a CrossCurve e utilizámos a sua solução para alguns dos nossos clientes. Definitivamente, quando o acidente aconteceu, tentámos avaliar de que forma afectou os nossos clientes e as nossas parcerias. E depois de uma verificação interna, reconhecemos que a boa notícia é que não houve impacto nos nossos clientes específicos.

O que aconteceu de facto? Assim, a CrossCurve utilizou alguns mensageiros externos que deveriam enviar uma mensagem da cadeia de origem para a cadeia de destino. O que significa, na verdade, que a CrossCurve disse que tinha, e tem, uma solução chamada ponte de consenso. Isso significa que utilizam diferentes mensageiros ao mesmo tempo para proteger a transação específica, o processo de lock-and-mint ou o processo de transferência de liquidez entre as cadeias. Mas neste caso específico, tiveram de embalar estas duas cadeias diferentes, pelo que utilizaram apenas a solução Axelar.

E o problema não está no CrossCurve, mas no mecanismo de mensagens Axelar. O que é que isto significa na prática? Quando alguém envia uma transação da cadeia de destino para a cadeia de origem, a cadeia de origem apenas verifica o ID da transação na cadeia de destino e compara os números, sem verificar realmente a mensagem da cadeia de origem. Infelizmente, muitos auditores e investigadores não mencionaram este facto como uma vulnerabilidade. Por esse motivo, a CrossCurve limitou-se a utilizar a mesma solução e os métodos aprovados pelos auditores externos.

Basicamente, mostra-nos que, por vezes, nem sequer podemos confiar totalmente nos auditores e que é necessário verificar duas vezes cada vez. Talvez aplicar algumas verificações adicionais de IA ou qualquer outra coisa. Mas a boa notícia é que a CrossCurve ainda está em jogo. E, definitivamente, há más notícias sobre ela, mas isso não significa que tenha problemas do ponto de vista da arquitetura. Podemos pensar nisto como um lembrete de como alguém pode abusar e atacar as pontes. Mas isso significa apenas que precisamos de fazer algumas verificações duplas, ter em mente que tais ataques podem acontecer e construir as próximas soluções e pontes entre cadeias de forma mais segura.

Muitas falhas de pontes são descritas como “casos extremos”. Serão estes incidentes realmente casos extremos ou sintomas de problemas arquitectónicos mais profundos?

Depende do caso. Posso dizer que os problemas de arquitetura mais comuns foram resolvidos durante o anterior mercado em alta, algures entre meados de 2020 e 2021. Por isso, os casos mais comuns já foram resolvidos nesta altura. Mas alguns casos são realmente casos extremos. Por exemplo, o caso do CrossCurve. Penso que se trata de um verdadeiro caso extremo porque, mesmo depois de todas as verificações, mesmo com uma boa arquitetura e uma ideia absolutamente brilhante, esses pontos fracos continuam a existir.

E, sem dúvida, penso que neste momento já temos a solução arquitetónica mais comum que pode existir. Chamamos-lhe uma norma de ouro para a indústria e, em geral, é uma norma comum, penso eu. Por isso, não se pode dizer que haja problemas arquitectónicos. Podemos dizer que podem ocorrer alguns pequenos erros ou pequenos casos invulgares, a que chamamos casos extremos.

Penso que o nosso principal objetivo neste momento é prevenir e proteger contra esses casos extremos a nível arquitetónico. É possível, por exemplo, utilizar uma solução híbrida, uma dupla verificação, uma auditoria adicional ou talvez um arrefecimento em alguns casos. Na nossa empresa, tentamos realmente implementar cada vez mais verificações e protecções de segurança e, por vezes, até preferimos reutilizar soluções existentes em vez de criar pontes a partir do zero.

E, neste caso, é definitivamente melhor aplicar a norma principal em vez de tentar reinventar a roda.

O Tron desempenha um papel único nos fluxos de stablecoin, especialmente para o USDT. Por que é que o encaminhamento Tron-to-EVM apresenta riscos diferentes dos da ponte EVM-to-EVM?

Penso que é a pergunta que nos faz qualquer um dos nossos clientes, ou mesmo qualquer pessoa que decida criar a sua própria cadeia personalizada. Na maioria dos casos, serão cadeias compatíveis com EVM, por vezes ZK-rollup de camada 2 ou rollup otimista. E todos querem ter uma parte da liquidez da cadeia Tron porque ela ainda desempenha um papel importante nas transferências de stablecoin: alguém é pago, recebe um salário ou paga contas usando stablecoins em Tron.

Definitivamente, qualquer pessoa quer ter acesso a esta liquidez e utilizá-la na sua própria cadeia personalizada. As cadeias compatíveis com Tron e EVM têm diferentes tipos de endereços, diferentes tipos de contratos inteligentes e diferentes linguagens para os contratos inteligentes. E é por isso que é tão difícil. Se ligarmos a cadeia EVM à cadeia EVM, o endereço na cadeia de destino e na cadeia de origem será o mesmo, e podemos utilizar o mesmo contrato inteligente para o lock-and-mint, mesmo do ponto de vista dos pagamentos das taxas de transação.

Assim, numa cadeia EVM, temos o mesmo mecanismo para estimar as taxas de gás e os custos de transação. Em Tron, é absolutamente diferente, com um conceito de energia, com pagamento em TRX, etc. É por isso que é tão diferente e mais complexo, em vez de se limitar a ligar duas cadeias diferentes compatíveis com EVM.

As pontes LP são vistas como a opção mais “nativa”. Em que momento é que a exigência de liquidez deste modelo se torna uma limitação estrutural e não um obstáculo temporário?

Sinceramente, penso que as pontes LP são a abordagem mais clássica para muitas cadeias. Significa que o utilizador, como alguém que pretende emparelhar a sua cadeia com uma cadeia externa, ou como proprietário da ponte, não precisa de fornecer a sua própria liquidez. Pode pedir à comunidade que lhe forneça essa liquidez e, na maioria dos casos, esta aceitará partilhar a sua liquidez consigo.

Mas é necessário proporcionar-lhes algum lucro. E irá competir com os protocolos DeFi existentes ou com outros casos de utilização de liquidez. Isto significa que a sua ponte deve ter muitas TVL bloqueadas e muitas transacções a atravessá-la. Se o volume de transacções for muito elevado e cobrar muitas comissões, poderá partilhar essas comissões com os fornecedores de liquidez.

Caso contrário, se houver menos transacções, isso significa que o fornecedor de LP tem menos razões para fornecer liquidez, uma vez que cobrará menos taxas. É por isso que eles podem decidir simplesmente remover a liquidez da sua ponte e usá-la num protocolo DeFi externo. Neste caso, a derrapagem nesta transação de LP, com esta ponte utilizando LP, será maior.

É por isso que alguém pode decidir: “Ok, não quero fazer a transação nesta cadeia com esta ponte e prefiro outra opção”.” Por isso, é preciso jogar com a liquidez e apresentar cada vez mais razões para apoiar a sua solução de ponte com a liquidez.

As pontes de bloqueio e de cunhagem eliminam a necessidade de liquidez comum, mas introduzem activos embrulhados. Na sua experiência, onde é que estas pontes tendem a falhar primeiro - tecnicamente, economicamente ou socialmente?

Definitivamente, não do ponto de vista social. A melhor parte da abordagem "lock-and-mint" é que não se tem qualquer liquidez. No caso das pontes de LP, é necessário pedir a alguém que forneça a liquidez aos LPs. Neste caso, nem sequer precisa de ter a sua própria liquidez.

Para a abordagem lock-and-mint, se alguém quiser utilizar algumas stablecoins ou utilizar a sua cadeia, poderá bloquear um certo número de stablecoins, ou qualquer que seja a moeda, na cadeia de origem, e depois cunhar um número igual na sua cadeia personalizada ou, em geral, na cadeia de destino.

Mas qual é o problema? O maior problema com esta abordagem é o facto de poder criar um tipo diferente de token na cadeia de destino. Trata-se, portanto, da fragmentação da liquidez. Por exemplo, haverá uma versão do token da Ethereum e outra da Arbitrum, ou diferentes tipos de tokens emitidos por diferentes pontes com uma abordagem de lock-and-mint. Trata-se, portanto, de fragmentação.

Mas também enfrenta alguns problemas de um ponto de vista técnico, porque se alguém atacar o mensageiro e enviar a mensagem errada de que é necessário desbloquear uma certa quantidade de fichas na cadeia de origem ou emitir um número adicional de fichas na cadeia de destino, então poderá obter a liquidez adicional que não é garantida pelas fichas reais na cadeia de origem.

Trata-se, portanto, de uma questão importante e, na maioria dos casos, quando alguém tenta atacar estas pontes, combina um ataque económico com um ataque técnico, mas não um ataque social.

A execução baseada na intenção promete uma experiência de utilizador forte e custos reduzidos. Onde é que este modelo começa a falhar quando os volumes aumentam ou as condições de mercado se alteram?

Concordo que uma abordagem baseada na intenção pode ser a melhor abordagem do ponto de vista da experiência do utilizador. Mas se criarmos a nossa própria cadeia, isso significa que temos de dar uma motivação adicional a alguns bots, algoritmos ou mesmo pessoas para serem o solucionador, porque os solucionadores são uma componente essencial da abordagem baseada na intenção.

Para muitos dos nossos clientes, utilizamos 1inch Fusion+. É exatamente uma abordagem baseada na intenção. Mas se quiser utilizar o mesmo para as suas próprias cadeias personalizadas, tem de motivar alguém para ser esse solucionador. Por exemplo, se virem cada vez menos volume de transacções na sua cadeia e cada vez menos pessoas que queiram fazer esta transferência, podem simplesmente tentar ditar-lhe as suas expectativas do ponto de vista das receitas, e então a experiência do utilizador torna-se cada vez pior.

E este baixo custo pode ser cada vez mais elevado, e a velocidade da transação pode ser mais lenta. Talvez o utilizador seja o único solucionador ou resolvedor que operará com esta abordagem. Por isso, penso que esta é a pior parte da abordagem baseada na intenção.

O modelo híbrido transfere a liquidez para fora da rede de destino. Que riscos é que este modelo elimina efetivamente e que riscos é que concentra?

Quando falamos de pontes em geral, se criarmos a nossa própria cadeia personalizada, queremos ligá-la ao ecossistema externo. Na maioria dos casos, tenho quase a certeza de que não se pretende ligar uma única cadeia a uma única cadeia externa.

Mas se utilizarmos a abordagem LP ou a abordagem lock-and-mint, isso significa que é necessário ligar a nossa cadeia única a muitas cadeias, o que é realmente dispendioso e requer muita liquidez. Na maioria dos casos, é normal escolher uma corrente como a sua corrente de origem e ligá-la à sua corrente. E, neste caso, com a sua cadeia de destino, pode ser uma abordagem "lock-and-mint".

Mas esta cadeia externa pode ser ligada a muitas, muitas, muitas outras cadeias externas de diferentes formas. Por exemplo, com a abordagem LP ou com uma abordagem baseada na intenção. Se criar o seu próprio L2 ZK-rollup e pretender aceder à liquidez do ecossistema externo, pode utilizar o Arbitrum como cadeia de origem.

O Arbitrum pode ser ligado ao Tron através de uma abordagem baseada na intenção e ao Ethereum através de uma abordagem LP. E então esta última milha será apenas uma abordagem de lock-and-mint para a sua cadeia. Assim, a solução híbrida permite-lhe ter acesso a qualquer liquidez externa em cadeias externas, mas com uma cadeia intermédia que utilizará como fonte para a sua própria cadeia personalizada.

Se uma equipa estiver a conceber uma rota de stablecoin de Tron para EVM agora, em 2026, qual é a primeira pergunta incómoda a que se deve obrigar a responder antes de escolher uma abordagem?

Penso que a pergunta mais incómoda é: quanto é que está disposto a gastar nesta solução de ponte? E quanto dinheiro está disposto a afetar a uma solução? Se estamos a falar de uma abordagem baseada na intenção, isso significa que, desde o início, terá de fornecer patrocínios ou outra razão para que os solucionadores continuem a ser solucionadores na sua cadeia. Se o tráfego na sua cadeia não for o maior desde o primeiro dia, terá realmente de patrocinar a sua solução. Se deixar de o fazer, na maioria dos casos, eles podem decidir desligar a sua solução.

Caso contrário, se estivermos a falar de uma abordagem "lock-and-mint", terá de pagar algum dinheiro aos mensageiros conhecidos para ligar a sua cadeia à sua rede de mensageiros. E é muito. Quer dizer, pagará centenas de milhares de dólares americanos só para ser ligado, e é um pagamento único.

Se estivermos a falar da abordagem LP, pode basicamente fornecer a sua própria liquidez. E isso continua a significar que pode ser o único fornecedor de LP para esta abordagem, mas esta liquidez será bloqueada. Ou pagará a alguém para bloquear a liquidez, o que também significa que terá de gastar algum stock dos seus próprios tokens ou, na melhor das hipóteses, um patrocínio adicional pela liquidez bloqueada.

Por isso, para mim, a primeira e mais importante questão é saber quanto é que está realmente disposto a gastar com isso e quanto dinheiro e tokens está disposto a atribuir a essas soluções.

Conheça o entrevistado

Andrew Nalichaev

Especialista em cadeias de blocos e analista de DeFi

Andrew traduz conceitos descentralizados em ferramentas financeiras seguras e funcionais. Ele navega no cenário volátil de DeFi para construir infraestruturas de blockchain escaláveis que abordam a utilidade do mundo real, indo além das palavras-chave para fornecer valor técnico.

Ver perfil

A experiência do Andrew em ação

Mais sobre este tema

Blogue

Como transferir USDT de Tron para EVM sem ficar preso pela liquidez

Blogue

Custo de desenvolvimento da troca de criptografia em 2026: repartição CEX vs. DEX

Blogue

Cadeias de bloqueio da camada 2 de topo: encontre a solução ideal para o seu projeto

Contactar-nos

Marcar uma chamada ou preencha o formulário abaixo e entraremos em contacto consigo assim que tivermos processado o seu pedido.

Nome

Empresa

Correio electrónico

Telefone

Mensagem

Envie-nos uma mensagem de voz

Anexar documentos

Enviar ficheiro

Pode anexar um ficheiro com um máximo de 2MB. Formatos de ficheiro válidos: pdf, jpg, jpeg, png.

Ao clicar em Enviar, o utilizador autoriza a Innowise a processar os seus dados pessoais de acordo com a nossa Política de privacidade para lhe fornecer informações relevantes. Ao enviar o seu número de telefone, o utilizador aceita que o possamos contactar através de chamadas de voz, SMS e aplicações de mensagens. Poderão ser aplicadas tarifas de chamadas, mensagens e dados.

Pode também enviar-nos o seu pedido
para contact@innowise.com

O que é que acontece a seguir?

Assim que recebermos e processarmos o seu pedido, entraremos em contacto consigo para necessidades do seu projeto e assinar um NDA para garantir a confidencialidade.

Depois de analisarmos os seus desejos, necessidades e expectativas, a nossa equipa elaborará uma proposta de projeto proposta de projeto com o âmbito do trabalho, dimensão da equipa, tempo e estimativas de custos.

Marcaremos uma reunião consigo para discutir a oferta e acertar os pormenores.

Por fim, assinaremos um contrato e começaremos a trabalhar no seu projeto imediatamente.