logo

URL del protocolo

Arquitectura

Image without caption

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.
    • GCP
      • t2d-standard-60 + pd-ssd con 60K IOPS.
Fuente:

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:
  • 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:

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:

Validadores de Tesnet

i) Archivos del validador:
docker-compose.yaml
  • Repositorio Git: 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
  • 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
  • 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
  • Comando de descarga:
    • shell
      wget -O fullnode.yaml https://raw.githubusercontent.com/aptos-labs/aptos-core/testnet/docker/compose/aptos-node/fullnode.yaml
Fuente:

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:
  • 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 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 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:

Exploradores de Aptos

  • Tesnet:
  • Mainnet:

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