🌌
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
  1. Materiais
  2. Learn
  3. Componentes de Infraestrutura

Guardians

Ou rede Guardiãs, em português.

A Wormhole confia em um conjunto de nós distribuídos que monitoram o estado de várias blockchains. Dentro da Wormhole, esses nós são chamados de Guardiãs. O conjunto atual de Guardiãs pode ser visualizado no Dashboard.

As Guardiãs têm o papel de observar mensagens e assinar os payloads correspondentes. Cada Guardiã executa essa etapa de forma isolada, combinando as assinaturas resultantes com as de outras Guardiãs como etapa final. A coleção resultante de observações independentes forma uma multisig, que representa a prova de que a maioria da rede Wormhole observou e concordou sobre um estado. Essas multisigs são chamadas de VAAs na Wormhole.

Rede de Guardiãs

A Rede de Guardiãs foi projetada para servir como o componente oracle da Wormhole, sendo a base técnica de todo o ecossistema Wormhole. É o elemento mais crítico da Wormhole e o componente mais essencial para se compreender, caso você queira um entendimento profundo.

Para entender não apenas como a Rede de Guardiãs funciona, mas também por que ela funciona da maneira que funciona, é importante revisar os principais critérios de design. Para se tornar uma plataforma de interoperabilidade de classe mundial, a Wormhole precisava de cinco características fundamentais:

  1. Descentralização: o controle da rede deve ser distribuído entre várias partes.

  2. Modularidade: diferentes partes do ecossistema, como o oracle, relayer e aplicações, devem ser mantidas separadas e modulares para permitir que sejam projetadas, modificadas e atualizadas de forma independente.

  3. Agnosticismo de Blockchain: a Wormhole deve suportar não apenas blockchains compatíveis com EVM, mas também cadeias como Solana, Algorand, Cosmos e até plataformas ainda não criadas. Nenhuma blockchain deve ser um ponto único de falha.

  4. Escalabilidade: a Wormhole deve ser capaz de garantir um alto valor de forma imediata e lidar com grandes volumes de transações.

  5. Atualizável: à medida que o ecossistema de computação descentralizada evolui, a Wormhole precisa ser capaz de alterar a implementação de seus módulos existentes sem afetar os integradores.

A seguir, examinaremos individualmente como a Wormhole alcança esses objetivos.

Descentralização

A descentralização é a maior preocupação. Soluções anteriores de interoperabilidade foram amplamente centralizadas e, mesmo soluções mais recentes com relayers adversários, ainda possuem pontos únicos de falha ou limites de conluio baixos.

Ao projetar uma rede oracle descentralizada, a primeira opção a considerar seria um sistema de Proof-of-Stake (PoS). No entanto, esta solução é subótima, pois o PoS é projetado para consenso em blockchains com contratos inteligentes e não é adequado para uma rede que verifica a saída de muitas blockchains. Além disso, a segurança de rede permanece incerta, dificultando outros objetivos.

Outra opção seria usar Provas de Conhecimento Zero (ZKP) para proteger a rede. Embora atraente pela confiança descentralizada, a tecnologia ZKP ainda está em estágio inicial e sua verificação on-chain não é viável, especialmente em blockchains com recursos computacionais limitados. Portanto, uma forma de multisig é necessária.

Na paisagem atual de De-Fi, a maioria das blockchains principais é assegurada pelas mesmas empresas de validadores de ponta. Se um protocolo puder unir muitas dessas empresas em um mecanismo de consenso projetado para interoperabilidade, ele será mais seguro e eficiente do que uma rede baseada em tokenomics.

Com esses fatores em mente, 19 Guardiãs é o número ideal, exigindo que dois terços das assinaturas (13) sejam verificadas on-chain, mantendo os custos de gas razoáveis. Essas Guardiãs não são anônimas, mas sim empresas robustas e amplamente conhecidas no espaço cripto.

Assim, a rede é formada por 19 Guardiãs com participação igual em um mecanismo de consenso baseado em Proof-of-Authority. À medida que as assinaturas de limite ganham suporte, o conjunto pode se expandir. Quando ZKPs se tornarem amplamente acessíveis, a Rede de Guardiãs se tornará totalmente descentralizada.

Modularidade

A Rede de Guardiãs é confiável por si só, permitindo que outros componentes, como o relayer, sejam simples e focados em suas funções. As Guardiãs verificam apenas atividades on-chain e produzem VAAs, enquanto os relayers interagem com blockchains para entregar mensagens.

A modificação do esquema de assinatura dos VAAs não afeta os usuários finais, e múltiplos mecanismos de relay podem coexistir de forma independente.

Agnosticismo de Blockchain

Hoje, a Wormhole suporta um espectro mais amplo de ecossistemas do que qualquer outro protocolo de interoperabilidade. Isso é possível devido à simplicidade de suas tecnologias, como assinaturas t-schnorr, modelo de relayers heterogêneos e rede robusta de validadores.

Escalabilidade

A Wormhole já demonstrou sua escalabilidade ao lidar com grandes volumes de valor total bloqueado (TVL) e transações. As Guardiãs precisam operar nós completos de todas as blockchains no ecossistema, mas, após configurados, a sobrecarga computacional é leve.

Atualizável

A Wormhole é projetada para evoluir. Assinaturas de limite permitirão a expansão do conjunto de Guardiãs, enquanto ZKPs e novos modelos de relay serão integrados à medida que amadurecem.

Com esses fundamentos, a Wormhole está traçando o caminho para uma camada de interoperabilidade totalmente descentralizada.

PreviousVAAs (Verified Action Approvals)NextSpy

Last updated 5 months ago