F.A.Q. Wormhole NTT
Você tem um exemplo de como o empréstimo cross-chain pode ser implementado usando Wormhole?
Sim, temos um exemplo de empréstimo cross-chain que utiliza a Ponte de Tokens do Wormhole. Neste exemplo, depósitos de colaterais (como ETH na Ethereum) são transferidos para uma cadeia hub. Após o depósito do colateral, os ativos emprestados, como BNB embrulhado, são transferidos para a Binance Smart Chain. Você pode explorar a implementação completa neste repositório de exemplo de empréstimo cross-chain.
Alternativamente, também é possÃvel implementar o empréstimo cross-chain usando a mensageria central do Wormhole, em vez da Ponte de Tokens, o que evita as limitações impostas por limites de governadores. O ETH seria custodiado na Ethereum, e o BNB na cadeia spoke da Binance durante essa configuração. Quando um usuário deposita ETH na Ethereum, uma mensagem central da ponte é enviada para o hub para fins de contabilidade. O hub então emite uma mensagem que pode ser resgatada na Binance para liberar o BNB. Essa abordagem permite um controle mais direto dos ativos entre as cadeias, enquanto reduz a dependência dos limites da Ponte de Tokens.
O que causa o erro "No protocols registered for EVM" no SDK do Wormhole?
Esse erro ocorre tipicamente quando o SDK do Wormhole não consegue reconhecer ou registrar os protocolos EVM necessários, que são requeridos para interagir com redes baseadas em Ethereum. A razão mais comum para esse erro é que o pacote EVM relevante para o NTT do Wormhole não foi importado corretamente.
Para resolver esse problema, certifique-se de que você importou o pacote apropriado do SDK do Wormhole para ambientes EVM. O pacote necessário para lidar com o NTT em cadeias EVM é o @wormhole-foundation/sdk-evm-ntt. Aqui está a declaração de importação correta:
Ao importar este pacote, o SDK do Wormhole poderá registrar e utilizar os protocolos necessários para cadeias EVM, possibilitando transferências cross-chain de tokens usando o framework NTT. Certifique-se de incluir essa importação no inÃcio do seu código, especialmente antes de tentar interagir com cadeias EVM em seu projeto.
Como posso transferir a propriedade do NTT para um multisig?
A transferência de propriedade do NTT do Wormhole para um multisig é um processo de duas etapas para garantir a segurança. Isso garante que a propriedade não seja transferida para um endereço que não possa reivindicá-la. Consulte o método transfer_ownership no Contrato do NTT Manager para iniciar a transferência.
Iniciar a transferência - use o método transfer_ownership no contrato NTT Manager para definir o novo proprietário (o multisig).
Reivindicar a propriedade - o multisig deve então reivindicar a propriedade por meio da instrução claim_ownership. Se não for reivindicado, o proprietário atual pode cancelar a transferência.
Transferência em uma única etapa (Mais arriscado): você também pode usar o método transfer_ownership_one_step_unchecked para transferir a propriedade em uma única etapa, mas se o novo proprietário não puder assinar, o contrato pode ser bloqueado. Seja cauteloso e certifique-se de que o novo proprietário seja um Endereço Derivado de Programa (PDA).
Como posso especificar um RPC personalizado para o NTT?
Para especificar um RPC personalizado para o NTT do Wormhole, crie um arquivo overrides.json no diretório raiz da sua implementação. Este arquivo permite que você defina endpoints RPC personalizados, o que pode ser útil quando você precisar se conectar a nós ou redes especÃficas para melhor desempenho, segurança ou controle sobre a conexão RPC.
Aqui está um exemplo de como o arquivo overrides.json deve ser estruturado:
Como posso resgatar tokens se os limites de taxa do NTT bloquearem o recebimento na cadeia de destino?
Se os limites de taxa do NTT do Wormhole bloquearem os tokens de serem recebidos na cadeia de destino, a transação será normalmente pausada até que os limites de taxa sejam ajustados. Limites de taxa são implementados para gerenciar congestionamento e prevenir abusos da cadeia, mas podem ocasionalmente atrasar os resgates de tokens.
Para resolver isso:
Ajuste os limites de taxa - os limites de taxa devem ser modificados por um administrador ou por meio das ferramentas de configuração apropriadas para permitir que a transação bloqueada prossiga.
Retomar o fluxo da transação - uma vez que os limites de taxa sejam ajustados, você pode retomar o fluxo, que deverá ser visÃvel na interface de usuário. Os tokens poderão ser resgatados na cadeia de destino.
Na maioria dos casos, a transação será retomada automaticamente assim que os limites de taxa forem ajustados, e a interface de usuário guiará você pelo processo de resgate.
Quais são os desafios ao implantar o NTT em cadeias não-EVM?
O NTT requer o mesmo transceptor para todas as rotas, limitando a flexibilidade ao implantar em cadeias EVM e não-EVM. Por exemplo, ao implantar na Ethereum, Arbitrum e Solana, você não pode usar Wormhole e Axelar como transceptores, pois Axelar não suporta Solana. Essa limitação força os integradores a usar um único transceptor (por exemplo, Wormhole) para todas as cadeias, reduzindo a flexibilidade na otimização das transferências cross-chain.
O gerenciador NTT funciona como uma conta escrow para uma cadeia hub?
Sim, o gerenciador NTT funciona como uma conta escrow para tokens não transferÃveis em uma cadeia hub. Para gerenciar tokens não transferÃveis, você adicionaria o gerenciador NTT à lista permitida, garantindo que apenas o gerenciador NTT possa reter e controlar os tokens enquanto são transferidos entre as cadeias.
Quais funções ou eventos o Connect depende para integração com o NTT?
O Connect depende do SDK NTT para integração, com implementações especÃficas para plataformas Solana e EVM. As principais funções envolvidas incluem:
Funções de iniciar e resgatar - essas funções são essenciais para iniciar as transferências de tokens e resgatar os tokens na cadeia de destino.
Métodos de capacidade de taxa - métodos para buscar os limites de taxa de entrada e saÃda também são crÃticos para controlar o fluxo de tokens e prevenir congestionamento.
Essas funções garantem que o Connect possa lidar com transferências de tokens e gerenciar os limites de taxa entre as cadeias.
Como o contrato relayer determina qual transceptor chamar?
O transceptor da cadeia de origem inclui o transceptor da cadeia de destino na mensagem via o contrato relayer. O administrador configura o mapeamento de cada transceptor com seus pares em outras cadeias. Esse mapeamento permite que o transceptor de destino verifique se a mensagem veio de uma fonte confiável.
Como posso criar um verificador ou transceptor?
Para rodar seu verificador, você precisa implementar um transceptor. Isso envolve aproximadamente 200 linhas de código, aproveitando a funcionalidade básica fornecida pelo contrato transceptor abstrato.
Como referência, você pode revisar a implementação do transceptor Axelar.
Posso usar Hetzner para o deploy do NTT?
Não, não é recomendado usar servidores Hetzner para implementações Solana. O Hetzner bloqueou a atividade da rede Solana em seus servidores, levando a problemas de conexão. Os nós do Hetzner retornarão um erro ConnectionRefused: Unable to connect para implantações Solana. Portanto, é aconselhável escolher provedores de hospedagem alternativos que suportem implantações Solana para garantir uma operação sem problemas.
Como posso transferir tokens com NTT com um payload adicional?
Você pode incluir um payload extra nas mensagens NTT sobrescrevendo métodos especÃficos no contrato NttManager.
Na cadeia de origem, sobrescreva a função _handleMsg para consultar quaisquer dados adicionais necessários para a transferência. O payload extra pode ser adicionado à mensagem.
Na cadeia de destino, sobrescreva a função _handleAdditionalPayload para processar e utilizar o payload extra enviado na mensagem.
Importante: você não pode passar os dados adicionais como parte do ponto de entrada diretamente. Em vez disso, os dados devem ser consultados na cadeia por meio do método _handleMsg, garantindo que o payload seja adequadamente incluÃdo e processado.
Por que usar NTT em vez de xERC20?
Limitações do xERC20:
Ponto único de falha - o xERC20 depende de várias pontes, mas uma falha em qualquer ponte pode comprometer o token. Ele força um design 1-de-n em vez de uma abordagem mais robusta m-de-n.
Sem pausas - o xERC20 não tem mecanismos para pausar operações durante emergências.
Sem controle de acesso - não há controles de acesso internos para gerenciar transferências de tokens de forma segura.
Limitação de taxa limitada - limites de taxa são especÃficos de ponte e não podem ser definidos por cadeia, reduzindo flexibilidade e segurança.
Sem integração com sistemas de retransmissão - o xERC20 não suporta nativamente sistemas de retransmissão, limitando sua usabilidade em setups automatizados ou dinâmicos.
Embora o xERC20 seja uma extensão do padrão ERC20, o NTT é projetado como um framework, não um padrão rÃgido. Ele é compatÃvel com qualquer token que suporte funções de queima e cunhagem, permitindo que o gerenciador NTT atue como um cunhador.
Posso definir IsSpecializedRelayer como verdadeiro via CLI?
Atualmente não. No entanto, estamos trabalhando para habilitar essa funcionalidade. Assim que a versão mais recente do CLI for lançada e você tiver atualizado, será possÃvel definir IsSpecializedRelayer como verdadeiro via CLI.
Como posso começar a transferir tokens para uma cadeia que está no modo de queima, se nenhum token foi bloqueado ainda?
Para começar a transferir tokens para uma cadeia em modo de queima quando nenhum token foi bloqueado, você deve primeiro enviar tokens para o gerenciador NTT para garantir o fornecimento. O endereço do gerenciador NTT pode ser encontrado no arquivo deployment.json.
Last updated