logo

URL do protocolo

Arquitetura

Image without caption

Requisitos de hardware (Tesnet e Mainnet)

  • CPU: 32 núcleos, 2,8 GHz ou mais, AMD Milan EPYC ou Intel(R) Xeon(R) Platinum
  • Memória: 64 GB de RAM.
  • Armazenamento: SSD de 2T com pelo menos 60K IOPS e largura de banda de 200MiB/s.
    • Comece com 700 GB se você puder fazer upgrade do armazenamento.
  • Largura de banda da rede: 1 Gbps Em geral, o tamanho do banco de dados em cada máquina é uma função do histórico do registro (ou seja, o número de transações no histórico do blockchain) e do número de estados no blockchain (por exemplo, contas e recursos). Tanto o histórico do ledger quanto o número de estados na cadeia dependem de vários fatores adicionais, como a idade da blockchain, a taxa média de transações ao longo do tempo e a configuração do podador do banco de dados do ledger. No momento em que este artigo foi escrito, estimamos que testnet e mainnet exigem várias centenas de GB de armazenamento.
  • Exemplos de tipos de máquinas que atendem às especificações de referência (em várias nuvens):
    • AWS
      • c6id.16xlarge (se estiver usando um SSD local).
      • c6i.16xlarge + volume EBS io2 com 60.000 IOPS.
    • GCP
      • t2d-standard-60 + pd-ssd com 60 mil IOPS.
  • Fonte:

Tipos de nós

  • Nós de validação
Quando uma transação é enviada para o blockchain do Aptos, os nós validadores executam um [protocolo de consenso] distribuído (https://aptos.dev/reference/glossary#consensus-protocol), executam a transação e armazenam os resultados da transação e da execução no blockchain. Os nós de validação decidem quais transações serão adicionadas ao blockchain e em que ordem.
  • Fonte:
  • Nós completos
Os Nós completos podem ser executados por qualquer pessoa. Os nós completos verificam o histórico da blockchain reexecutando todas as transações no histórico da blockchain da Aptos ou reproduzindo a saída de cada transação. Os nós completos replicam o estado completo da blockchain sincronizando com participantes upstream, por exemplo, outros nós completos ou nós validadores. Para verificar o estado da blockchain, os nós completos recebem o conjunto de transações e a [raiz de hash acumulada] (https://aptos.dev/reference/glossary#accumulator-root-hash) do livro-razão assinado pelos validadores. Além disso, os nós completos aceitam transações enviadas por clientes Aptos e as encaminham direta (ou indiretamente) aos nós validadores. Embora os nós completos e os validadores compartilhem o mesmo código, os ós completos não participam do consenso.
  • Fonte:

Tipos de rede

  • Rede de validadores**: os validadores se conectam uns aos outros por meio dessa rede.Os nós completos do validador (VFN) e os nós completos públicos (PFN) não usam essa rede.
  • Rede VFN**: A rede de nós completos do validador (VFN) permite que um validador e um par de VFN se conectem entre si.Essa rede é privada entre o validador e o VFN.
  • Rede pública**: A rede pública permite que VFNs e fullnodes públicos (PFNs) se conectem a outros VFNs e PFNs.Isso permite que os operadores de nós públicos acessem o blockchain.

Validadores Tesnet

(i) Arquivos do validador:** docker-compose.yaml docker-compose.yaml
docker-compose.yaml
  • Repositório Git: aptos-core.
  • Comando de download:
    • shell
      wget -O docker-compose.yaml <https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/docker-compose.yaml>
validator.yaml
  • Repositório Git: aptos-core.
  • Comando de download:
    • shell
      wget -O validator.yaml <https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/validator.yaml>
ii) Arquivos VFN (Validator Full Node) ou PFN (Public Full Node): docker-compose-fullnode.yaml
  • Repositório Git: aptos-core.
  • Comando de download:
    • shell
      wget -O docker-compose-fullnode.yaml <https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/docker-compose-fullnode.yaml>
fullnode.yaml
  • Repositório Git: aptos-core
  • Comando de download:
    • shell
      wget -O fullnode.yaml <https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/fullnode.yaml>
      Fuente:
      Fonte:

      Segurança

      Cada um dos diferentes modos de sincronização de estado realiza verificações de integridade de dados para garantir que os dados que estão sendo sincronizados com o nó tenham sido produzidos e assinados corretamente pelos validadores. Isso ocorre de forma ligeiramente diferente para cada modo de sincronização:
    • Execução de transações**: A execução de transações do Genesis é o modo de sincronização mais seguro. Ele verificará se todas as transações desde o início do tempo foram corretamente acordadas por consenso e se todas as transações foram corretamente executadas pelos validadores. Todo o estado resultante da blockchain será verificado novamente pelo nó de sincronização.
    • Fonte.
    • Aplicação dos resultados da transação**: a aplicação dos resultados da transação genesis é mais rápida do que a execução de todas as transações, mas exige que o nó de sincronização confie que os validadores executaram as transações corretamente. No entanto, o restante do estado do blockchain ainda é verificado manualmente, por exemplo, mensagens de consenso, histórico de transações e hashes de status.
    • Fonte:** [State Synchronisation
    • Sincronização inteligente**: a sincronização inteligente executará ou aplicará saídas de transação com base no que for mais rápido, por pedaço de dados. Portanto, as implicações de segurança do uso desse modo são idênticas às da aplicação de saídas de transação.
    • Fonte:** [State Synchronisation
    • Aplicação dos resultados da transação**: a aplicação dos resultados da transação genesis é mais rápida do que a execução de todas as transações, mas exige que o nó de sincronização confie que os validadores executaram as transações corretamente. No entanto, o restante do estado do blockchain ainda é verificado manualmente, por exemplo, mensagens de consenso, histórico de transações e hashes de status.
    • Fonte:** [State Synchronisation
    • Sincronização inteligente**: a sincronização inteligente executará ou aplicará saídas de transação com base no que for mais rápido, por pedaço de dados. Portanto, as implicações de segurança do uso desse modo são idênticas às da aplicação de saídas de transação.
    • Fonte:** [State Synchronisation
    • Sincronización rápida: La sincronización rápida se salta el historial de transacciones y descarga el último estado del blockchain antes de sincronizarlo continuamente. Para ello, requiere que el nodo de sincronización confíe en que los validadores han acordado correctamente todas las transacciones del historial de transacciones, así como que confíe en que todas las transacciones han sido ejecutadas correctamente por los validadores. Sin embargo, todos los demás estados de la cadena de bloques se vuelven a verificar manualmente, por ejemplo, los cambios de época y los estados resultantes de la cadena de bloques.
    • Fuente:
    • Sincronização rápida**: a sincronização rápida ignora o histórico de transações e faz o download do estado mais recente do blockchain antes de sincronizá-lo continuamente. Para isso, é necessário que o nó de sincronização confie que os validadores concordaram corretamente com todas as transações no histórico de transações, além de confiar que todas as transações foram executadas corretamente pelos validadores. No entanto, todos os outros estados do blockchain são verificados novamente de forma manual, por exemplo, mudanças de época e estados resultantes do blockchain.
    • Fonte:
    • Aptos Explorers

    • Tesnet:
    • Mainnet:
    • Configuração de porta

      Porta #
      Firewall/adaptador
      Finalidade
      Comentários
      6182
      aberto
      Rede pública de Aptos
      PFN
      9101 cerrado de Aptos PFN
      fechado
      Serviço de inspeção de Aptos
      PFN
      9102
      fechado
      Serviço de administração da Aptos
      PFN
      80/8080
      fechado
      API REST do Aptos
      PFN
      A porta do serviço de inspeção (9101), a porta do serviço de administração (9102) e a porta da API REST (80 ou 808080) provavelmente são úteis para sua rede interna, por exemplo, para desenvolvimento e depuração de aplicativos. No entanto, a porta do serviço de inspeção e a porta do serviço de gerenciamento nunca devem ser expostas publicamente, pois podem ser facilmente abusadas. Da mesma forma, se você optar por expor publicamente o ponto de extremidade da API REST, deverá implementar uma autenticação adicional ou um mecanismo de limitação de taxa para evitar abusos.

      Repositório do GitHub

    • Aptos core: https://github.com/aptos-labs/aptos-core