🌌
Wormhole Docs Brasil
  • Bem-vindo!
  • Materiais
    • Build
      • Começer a Buildar
        • Redes Suportadas
        • Testnet Faucets
        • Demos
      • Construindo Aplicações Frontend
        • Wormhole SDK
          • Wormhole TypeScript SDK
          • Data Layouts
          • Construção de Protocolos e Payloads
        • Queries
          • Overview
          • Usando Queries
          • F.A.Q.
        • Conexão
          • Overview
          • Routes
          • Features
          • Configuração
          • v1 Migration
          • F.A.Q.
      • Construindo Integrações de contratos
        • Wormhole Relayer
        • Core Contracts
        • CCTP
        • Transferências de Tokens Nativos
          • Processos de Deployment
        • Comandos NTT CLI
        • Configuração de NTT
          • Limitação de Taxas
          • Controle de Acesso
        • Managers e Transceivers
        • F.A.Q. Wormhole NTT
      • MultiGov
        • Deployment
        • Upgrades Contracts
        • F.A.Q. Tecnicas
      • Ambiente de Desenvolvimento
      • F.A.Q sobre Integrações de Contratos
      • Toolkit
        • Wormholescan
        • Wormhole CLI
        • Wormhole SDK
          • TypeScript SDK
          • Data Layouts
          • Construindo Protocolos e Payloads
        • Solidity SDK
        • Tilt
        • Toolkit F.A.Q.
      • Referências
    • Infraestrutura
      • Run a Relayer
      • Run a Spy
    • Tutoriais
      • Tutorial de Conexão
      • Tutorial de Contratos Cross-Chain
        • Criação de Contratos de Mensagens Cross-Chain
        • Criação de contratos de transferência de tokens Cross-Chain
      • Tutoriais de Transferências de Tokens Nativos (NTT - Native Token Transfers)
        • Crie Tokens Multichain
      • Tutorial MultiGov
        • Proposta Cross-Chain treasury management
      • Tutoriais do Wormhole SDK
        • Transferir USDC via CCTP
        • Transferir Tokens via a Token Bridge
    • Learn
      • Fundamentos
        • Introdução
        • Segurança
        • Overview de Arquitetura
        • Glossário
      • Componentes de Infraestrutura
        • Core Contracts
        • VAAs (Verified Action Approvals)
        • Guardians
        • Spy
        • Relayers
      • Messaging
        • Token Bridge
        • Circle's CCTP Bridge
        • Transferencias de Token Nativos
          • Overview
          • Arquitetura
          • Modelos de Deploy
          • Security
      • Multigov
        • MultiGov: Governança Cross-Chain com Wormhole
        • MultiGov Architecture
        • FAQs
    • Links úteis
Powered by GitBook
On this page
  • Componentes do Sistema#
  • Managers#
  • Transceivers#
  • Como funciona:
  • Transceivers Personalizados#
  • Recursos dos Transceivers Personalizados
  • O Verificador e o Processo de Validação
  • Ciclo de Vida de uma Mensagem#
  1. Materiais
  2. Learn
  3. Messaging
  4. Transferencias de Token Nativos

Arquitetura

A arquitetura Native Token Transfers (NTT) do ecossistema Wormhole oferece uma estrutura robusta para transferências seguras e eficientes de tokens entre várias blockchains. Essa arquitetura é baseada em dois componentes principais: managers e transceivers, que trabalham juntos para gerenciar a comunicação entre cadeias e as operações relacionadas aos tokens.

Para implementações técnicas das funções, consulte a página Managers and Transceivers.

Componentes do Sistema#

A estrutura NTT é composta por managers, responsáveis pelo processo de transferência, e transceivers, que lidam com a comunicação entre cadeias, garantindo transferências confiáveis e fluidas.

Managers#

Os managers gerenciam o fluxo de transferências de tokens entre blockchains, assegurando que os tokens sejam bloqueados ou queimados na cadeia de origem antes de serem cunhados ou desbloqueados na cadeia de destino.

Principais funções dos managers:

  1. Gerenciar o fluxo de transferências:

    • O NttManager bloqueia ou queima os tokens, emite um evento de transferência e garante que os tokens não sejam acessados na cadeia de origem antes de serem liberados na cadeia de destino, prevenindo o gasto duplo.

  2. Limitação de taxas:

    • O contrato NttManager aplica limites de transferência para evitar sobrecarga na rede:

      • Saída: Transferências acima do limite são colocadas em fila (se configurado) ou revertidas.

      • Entrada: Limites semelhantes aplicados na cadeia de destino podem atrasar transferências quando a capacidade é excedida.

    • Personalizável: A duração e as filas dos limites podem ser ajustadas por cadeia, com notificações emitidas em caso de excedentes.

  3. Verificação de autenticidade:

    • O NttManager valida a autenticidade das mensagens de transferência por meio de múltiplas atestações dos transceivers, garantindo que apenas transferências autenticadas sejam processadas.

  4. Interação com transceivers:

    • Os managers colaboram com os transceivers para encaminhar mensagens de transferência e verificar que os tokens foram bloqueados ou queimados antes de serem liberados na outra cadeia.

Transceivers#

Os transceivers facilitam as transferências de tokens entre cadeias, garantindo a transmissão precisa das mensagens e reforçando a segurança do processo.

Principais funções dos transceivers:

  1. Transmissão de mensagens:

    • Encaminham detalhes da transferência (como destinatário e valor) para o manager da cadeia de destino.

  2. Coordenação com managers:

    • Trabalham em conjunto com os managers para garantir que os tokens sejam bloqueados ou queimados antes de serem liberados.

  3. Suporte a verificações personalizadas:

    • Podem ser configurados para trabalhar com backends de verificação personalizados, adaptando-se a diferentes protocolos de segurança ou requisitos específicos.

Como funciona:

  1. O transceiver recebe instruções do manager para enviar mensagens entre cadeias.

  2. Calcula taxas de entrega, retransmite mensagens e verifica a entrega para assegurar transferências seguras.

  3. Coordena com os managers para garantir que apenas transferências autorizadas sejam processadas na cadeia de destino.

Transceivers Personalizados#

A estrutura NTT suporta recursos avançados, como transceivers personalizados para verificação especializada de mensagens, aprimorando a segurança e a adaptabilidade. A arquitetura detalha processos específicos para:

  • Iniciar transferências

  • Gerenciar limites de taxa

  • Finalizar operações de tokens

Instruções e eventos são definidos especificamente para cadeias compatíveis com EVM e Solana.

Recursos dos Transceivers Personalizados

  1. Verificação personalizada de mensagens:

    • A estrutura NTT permite a integração de verificações adicionais além das realizadas pelos Wormhole Guardians.

  2. Contratos de transceivers personalizados:

    • Implementados como contratos de transceivers, podem ser configurados de forma específica para cada protocolo ou fornecidos por terceiros.

  3. Configuração de limiares de atestação:

    • Protocolos podem definir o número de atestações necessárias para validar uma transferência de token.

      • Exemplos de limiares: 2/2, 2/3, 3/5, garantindo flexibilidade e segurança.

O Verificador e o Processo de Validação

O verificador realiza checagens com base em critérios predefinidos, aprovando transações que atendem a esses requisitos. Essa aprovação é incorporada à mensagem Wormhole, garantindo que apenas transações verificadas pela Wormhole Guardian Network e pelo verificador adicional sejam processadas. Este modelo inclui um verificador extra no processo de bridging, aumentando a segurança e fornecendo uma garantia adicional de integridade nas transações.

Para mais detalhes, colaboração ou exemplos de transceivers personalizados, entre em contato com os contribuidores da Wormhole.

Ciclo de Vida de uma Mensagem#

O ciclo de vida de uma mensagem no ecossistema Wormhole para Native Token Transfers (NTT) envolve várias etapas para assegurar transferências cross-chain seguras e precisas. Este ciclo varia dependendo da blockchain utilizada, com foco nas implementações para EVM e Solana.

As principais etapas incluem:

  1. Iniciar a Transferência

  2. Gerenciar Limites de Taxa

  3. Enviar e Receber Mensagens

  4. Mintar ou Desbloquear Tokens

1. Transferência

  • EVM: O cliente utiliza a função transfer.

  • Solana: O cliente usa as instruções transfer_lock ou transfer_burn, dependendo se o programa está em modo de bloqueio ou queima.

Processo:

  • Tokens são bloqueados na cadeia de origem para serem desbloqueados na cadeia de destino (modo de bloqueio).

  • Tokens são queimados na origem, e novos tokens são mintados no destino (modo de queima).

  • Um evento, como TransferSent (EVM) ou um log correspondente em Solana, sinaliza o início do processo.

2. Limite de Taxa

Ambas as blockchains aplicam limites de taxa para evitar abusos ou sobrecarga de rede.

  • EVM:

    • Transferências que excedem o limite são colocadas em fila (se shouldQueue = true) ou revertidas com erro.

  • Solana:

    • Transferências são adicionadas ao Outbox com um timestamp de liberação. Se o limite for atingido e shouldQueue = false, a transferência retorna o erro TransferExceedsRateLimit.

Eventos ou logs são gerados quando transferências atingem o limite ou são colocadas em fila.

3. Envio

A mensagem é transmitida entre cadeias pelo Transceiver, que envia os detalhes da transferência.

  • EVM:

    • A função sendMessage lida com a transmissão, podendo usar relays Wormhole ou soluções customizadas.

  • Solana:

    • Mensagens são colocadas no Outbox e liberadas com a instrução release_outbound, observada pelos Wormhole Guardians para verificação.

Eventos como SendTransceiverMessage (EVM) ou logs equivalentes em Solana indicam a transmissão bem-sucedida.

4. Recepção

Ao receber a mensagem, um relayer off-chain a encaminha para o Transceiver no destino.

  • EVM:

    • A mensagem é processada pelo NttManager, que verifica sua autenticidade com base no limiar de atestação configurado (M de N).

  • Solana:

    • A mensagem é verificada e armazenada em uma conta VerifiedTransceiverMessage antes de ser processada na Inbox.

Mecanismos de proteção contra replay garantem que a mensagem não seja executada mais de uma vez.

5. Mintar ou Desbloquear

Após a verificação:

  • EVM: Tokens são mintados (se queimados na origem) ou desbloqueados (se bloqueados na origem). O evento TransferRedeemed indica sucesso.

  • Solana: Tokens são desbloqueados ou mintados com as instruções release_inbound_unlock ou release_inbound_mint, gerando um log correspondente.

Uma vez concluído, o destinatário recebe os tokens, finalizando o processo de transferência cross-chain. Eventos confirmam o resgate total da transferência.

PreviousOverviewNextModelos de Deploy

Last updated 5 months ago