Saltar al contenido principal

Operar un nodo

Todavía no está abierto

Hoy la red funciona solo con los 4 nodos de almacenamiento que opera el proyecto. Los operadores independientes (más nodos y más shards), junto con el staking de terceros, las recompensas y las penalizaciones, están en el roadmap.

Esta página explica, como referencia, qué hace un nodo y cómo entra en la red.

Qué hace un nodo de almacenamiento​

  • Sigue IOTA. Lee del objeto Staking la época, el comité y sus shards, y sigue los eventos del paquete almacen (registros, certificaciones, renovaciones, borrados).
  • Guarda datos. Acepta los metadatos y los slivers de los blobs registrados para sus shards, comprueba los metadatos frente al blob ID y los guarda en disco.
  • Firma confirmaciones. Cuando tiene los metadatos y todos sus slivers de un blob, firma una confirmación con su clave BLS. Los clientes agregan esas confirmaciones para certificar el blob en IOTA.
  • Sirve lecturas de metadatos y slivers con su API HTTP.
  • Borra los datos caducados, cuando un blob ID se queda sin registros vigentes.
  • Hace avanzar las épocas. Llama a voting_end a mitad de época, a initiate_epoch_change_v2 al final y a epoch_sync_done cuando está listo para la época nueva. Si otro nodo se adelanta, no se gasta nada.

Guarda su estado en disco (cursor de eventos, índice de blobs y épocas confirmadas), así que al reiniciarse sigue donde lo dejó.

Software​

El nodo está escrito en Node.js (nodo.mjs, en el repositorio del proyecto, todavía no público), con la API REST, los formatos BCS y la codificación RS2 que describen estas páginas. Un supervisor (servir.mjs) lanza un proceso por nodo, lo vuelve a arrancar si se cae y lanza también el aggregator, el publisher y el portal.

Entrar en el comité​

En la cadena, un nodo entra con IOTA:

  1. staking::register_candidate: registra el nodo con su nombre, su dirección de red, su clave pública BLS y la prueba de posesión de esa clave, su clave pública de red, su comisión, los precios de almacenamiento y de escritura que vota y su capacidad. El operador recibe un StorageNodeCap.
  2. staking::stake_with_pool: stake de al menos 1 IOTA en el nodo.
  3. En el siguiente cambio de época, el comité se elige por stake y se asignan shards al nodo.

La dirección de red (por ejemplo, nodo-1.iotastorage.com:443) es donde los clientes encuentran al nodo; con las direcciones del puerto 443 se usa HTTPS.

Limitaciones actuales​

  • Sin recuperación de slivers entre nodos ni migración de shards cuando cambia el comité. Un nodo que estuvo parado ve los blobs registrados entretanto, pero no recupera sus slivers.
  • Sin desafíos de almacenamiento ni pruebas de inconsistencia.
  • El nodo comprueba los metadatos, el índice y el tamaño de cada sliver, pero no su contenido frente a su hash (exige expandirlo con Reed-Solomon, y la biblioteca de codificación que se usa no lo permite). Quien lee comprueba siempre el blob ID, así que nunca se aceptan datos falsos, pero un cliente malicioso podría subir slivers inconsistentes de su propio blob.
  • La clave de red (secp256r1) se registra, pero no se usa para TLS entre clientes y nodos.

Estos puntos forman parte del paso de «robustez» del roadmap.