Skip to main content

Operate a node

Not open yet

Today the network runs only the 4 storage nodes operated by the project. Independent operators (more nodes and more shards), together with staking by third parties, rewards and penalties, are on the roadmap.

This page explains what a node does and how it joins the network, for reference.

What a storage node does​

  • Follows IOTA. It reads the epoch, the committee and its shards from the Staking object, and follows the events of the almacen package (registrations, certifications, renewals, deletions).
  • Stores data. It accepts the metadata and the slivers of registered blobs for its shards, checks the metadata against the blob ID, and keeps them on disk.
  • Signs confirmations. When it has the metadata and all its slivers of a blob, it signs a confirmation with its BLS key. Clients aggregate these confirmations to certify the blob on IOTA.
  • Serves reads of metadata and slivers through its HTTP API.
  • Deletes expired data, when a blob ID has no valid registration left.
  • Advances the epochs. It calls voting_end halfway through the epoch, initiate_epoch_change_v2 at its end, and epoch_sync_done once it is ready for the new epoch. If another node did it first, nothing is spent.

It keeps its state on disk (event cursor, index of blobs and confirmed epochs), so it continues where it left off after a restart.

Software​

The node is written in Node.js (nodo.mjs in the project repository, not public yet), with the REST API, the BCS formats and the RS2 encoding described in these pages. A supervisor (servir.mjs) runs one process per node, restarts it if it fails, and also runs the aggregator, the publisher and the portal.

Joining the committee​

On-chain, a node joins with IOTA:

  1. staking::register_candidate: registers the node with its name, network address, BLS public key and proof of possession of that key, network public key, commission, the storage and write prices it votes for, and its capacity. The operator receives a StorageNodeCap.
  2. staking::stake_with_pool: stake of at least 1 IOTA on the node.
  3. At the next change of epoch, the committee is chosen by stake and shards are assigned to the node.

The network address (for example nodo-1.iotastorage.com:443) is where clients reach the node; addresses on port 443 are reached over HTTPS.

Current limitations​

  • No recovery of slivers between nodes and no migration of shards when the committee changes. A node that was stopped sees the blobs registered meanwhile but does not recover their slivers.
  • No storage challenges and no inconsistency proofs.
  • The node checks the metadata, the index and the size of each sliver, but not its content against its hash (that requires Reed–Solomon expansion, not available in the encoding library used). Readers always check the blob ID, so wrong data is never accepted, but a malicious client could upload inconsistent slivers of its own blob.
  • The network key (secp256r1) is registered but not used for TLS between clients and nodes.

These items are part of the "robustness" step of the roadmap.