Aptos

URL do protocolo

Fundação Aptos: https://aptosfoundation.org/get-started

Laboratório Aptos: https://aptoslabs.com/

Operadores de nós: https://aptos.dev/nodes/nodes-landing/

Arquitetura

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.

t2d-standard-60 + pd-ssd com 60 mil IOPS.

Fonte:

Node Requirements | Aptos Docs

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:

Overview of validator nodes | Aptos Docs

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:

Fullnode Overview | Aptos Docs

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.

Fonte: Node Requirements | Aptos Docs

Validadores Tesnet

(i) Arquivos do validador:** docker-compose.yaml docker-compose.yaml

docker-compose.yaml

Repositório Git: aptos-core.

Git branch: testnet em https://github.com/aptos-labs/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.

Git branch: testnet em https://github.com/aptos-labs/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.

Git branch: testnet em https://github.com/aptos-labs/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

Ramo do Git: testnet em https://github.com/aptos-labs/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:

Archivos Para Testnet | Aptos Docs

Fonte:

Testnet Files | Aptos Docs

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.

State Synchronisation | Aptos Docs

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

State Synchronisation | Aptos Docs

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

State Synchronisation | Aptos Docs

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

State Synchronisation | Aptos Docs

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

State Synchronisation | Aptos Docs

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:

Sincronización de estados | Aptos Docs

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:

State Synchronisation | Aptos Docs

Aptos Explorers

Tesnet:

Aptos Explorer

Mainnet:

Aptos Explorer

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