Aptos

URL del protocolo

Fundación Aptos: https://aptosfoundation.org/get-started

Laboratorio de Aptos: https://aptoslabs.com/

Operadores de nodo: https://aptos.dev/nodes/nodes-landing/

Arquitectura

Requisitos de Hardware (Tesnet y Mainnet)

CPU: 32 núcleos, 2,8 GHz o superior, AMD Milan EPYC o Intel(R) Xeon(R) Platinum

Memoria: 64 GB DE RAM.

Almacenamiento: 2T SSD con al menos 60K IOPS y 200MiB/s de ancho de banda.

Empieza con 700GB si puedes actualizar el almacenamiento

Ancho de banda de red: 1Gbps

Generalmente, el tamaño de la base de datos en cada máquina es una función del historial del libro mayor (es decir, el número de transacciones en el historial de la cadena de bloques) y el número de estados en la cadena (por ejemplo, cuentas y recursos). Tanto el historial del libro mayor como el número de estados en la cadena dependen de varios factores adicionales, como la antigüedad de la cadena de bloques, la tasa media de transacciones a lo largo del tiempo y la configuración del podador de la base de datos del libro mayor. En el momento de escribir estas líneas, estimamos que testnet y mainnet requieren varios cientos de GB de almacenamiento.

Ejemplos de tipos de máquinas que cumplen las especificaciones de referencia (en varias nubes):

AWS

c6id.16xlarge (si se utiliza un SSD local).
c6i.16xlarge + volumen EBS io2 con 60.000 IOPS.

t2d-standard-60 + pd-ssd con 60K IOPS.

Fuente:

Requisitos de Nodo | Aptos Docs

Tipos de nodos

Nodos validadores

Cuando se envía una transacción a la cadena de bloques de Aptos, los nodos validadores ejecutan un [protocolo de consenso] distribuido (https://aptos.dev/reference/glossary#consensus-protocol), ejecutan la transacción y almacenan la transacción y los resultados de la ejecución en la cadena de bloques. Los nodos validadores deciden qué transacciones se añadirán a la cadena de bloques y en qué orden.

Fuente:

Descripción general de los nodos validadores | Aptos Docs

Nodos completos

Los Fullnodes pueden ser ejecutados por cualquiera. Los Fullnodes verifican la historia de la blockchain reejecutando todas las transacciones en la historia de la blockchain de Aptos o reproduciendo la salida de cada transacción. Los fullnodes replican el estado completo de la cadena de bloques sincronizándose con los participantes anteriores, por ejemplo, otros fullnodes o nodos validadores. Para verificar el estado del blockchain, los fullnodes reciben el conjunto de transacciones y la raíz hash acumuladora del libro mayor firmada por los validadores. Además, los fullnodes aceptan las transacciones enviadas por los clientes de Aptos y las reenvían directamente (o indirectamente) a los nodos validadores. Aunque los fullnodes y los validadores comparten el mismo código, los fullnodes no participan en el consenso.

Fuente:

Visión general de Fullnodes | Aptos Docs

Tipos de red

Red de validadores: Los validadores se conectan entre sí a través de esta red. Los nodos completos de validador (VFN) y los nodos completos públicos (PFN) no utilizan esta red.

Red VFN: La red de nodos completos de validador (VFN) permite que un par de validador y VFN se conecten entre sí. Esta red es privada entre el validador y el VFN.

Red pública: La red pública permite a los VFN y a los fullnodes públicos (PFN) conectarse a otros VFN y PFN. Esto permite a los operadores de nodos públicos acceder al blockchain.

Fuente:

Requisitos del nodo | Aptos Docs

Validadores de Tesnet

i) Archivos del validador:

docker-compose.yaml

Repositorio Git: aptos-core

Rama de Git: testnet en https://github.com/aptos-labs/aptos-core

Comando de descarga:

shell
wget -O docker-compose.yaml <https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/docker-compose.yaml>

validator.yaml

Repositorio Git: aptos-core

Rama de Git: testnet en https://github.com/aptos-labs/aptos-core

Comando de descarga:

shell
wget -O validator.yaml https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/validator.yaml

ii) Archivos VFN (Validator Full Node) o PFN (Public Full Node): docker-compose-fullnode.yaml

Repositorio Git: aptos-core

Rama Git: testnet en https://github.com/aptos-labs/aptos-core

Comando de descarga:

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

Repositorio Git: aptos-core

Rama de Git: testnet en https://github.com/aptos-labs/aptos-core

Comando de descarga:

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

Seguridad

Cada uno de los diferentes modos de sincronización de estado realiza verificaciones de integridad de los datos para garantizar que los datos que se sincronizan con el nodo han sido correctamente producidos y firmados por los validadores. Esto ocurre de forma ligeramente diferente para cada modo de sincronización:

Ejecución de transacciones**: Ejecutar transacciones desde genesis es el modo de sincronización más seguro. Verificará que todas las transacciones desde el principio de los tiempos fueron correctamente acordadas por consenso y que todas las transacciones fueron correctamente ejecutadas por los validadores. Todo el estado resultante de la cadena de bloques será verificado de nuevo por el nodo de sincronización.

Fuente:

Sincronización de estados | Aptos Docs

Aplicación de resultados de transacciones**: Aplicar los resultados de las transacciones de genesis es más rápido que ejecutar todas las transacciones, pero requiere que el nodo de sincronización confíe en que los validadores han ejecutado las transacciones correctamente. Sin embargo, el resto del estado de la cadena de bloques se sigue verificando manualmente, por ejemplo, los mensajes de consenso, el historial de transacciones y los hashes de estado.

Fuente:

Sincronización de estados | Aptos Docs

Sincronización inteligente**: La sincronización inteligente ejecutará o aplicará las salidas de transacción en función de lo que sea más rápido, por trozo de datos. Por lo tanto, las implicaciones de seguridad de utilizar este modo son idénticas a las de aplicar salidas de transacciones.

Fuente:

Sincronización de estados | 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

Exploradores de Aptos

Tesnet:

Explorador de Aptos

Mainnet:

Explorador de Aptos

Configuración de puertos

Puerto #	Firewall/adaptador	Propósito	Comentarios
6182	abierto	Aptos Red pública	PFN
9101 cerrado de Aptos PFN	cerrado	Aptos Servicio de inspección	PFN
9102	cerrado	Aptos Servicio de admin	PFN
80/8080	cerrado	Aptos REST API	PFN

El puerto del servicio de inspección (9101), el puerto del servicio de administración (9102) y el puerto de la API REST (80 o 8080) son probablemente útiles para su red interna, por ejemplo, para el desarrollo y depuración de aplicaciones. Sin embargo, el puerto del servicio de inspección y el puerto del servicio de administración nunca deben exponerse públicamente, ya que se puede abusar fácilmente de ellos. Del mismo modo, si decide exponer públicamente el punto final de la API REST, debe implementar un mecanismo adicional de autenticación o limitación de velocidad para evitar abusos.

Repositorio GitHub

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