IOTA is a unique distributed ledger technology which was born in 2014 out of a hardware initiative intended to support general distributed computing as the groundwork for the IoT infrastructure of inter-connected devices.

The IOTA foundation is dedicated to developing industrial standards and open protocols for a machine-to-machine economy, ensuring the real-time circulation of validated, well-defined and clear-cut data and the securing of critical infrastructure on a global scale.

Running a IOTA node is a way to enter the network which is called the “tangle”. The Tangle is an example of a Directed Acyclic Graph (DAG) based cryptocurrency. The node can function as a load balancer to the Tangle and helps by speeding up confirmation times in a given segment of the network while receiving weekly distributed donations for doing so.

In the following sections we’ll focus on some of the key components which constitute the IOTA protocol and network infrastructure. We will then provide instructions on how to set up and operate a node, as well as some of the applications, use cases and available tools.

So, if you are interested in setting up your own full node in the comfort of your home, read on..

Seeds, Keys, Addresses and Transactions

A IOTA seed is the starting point of creating a transactions channel. A seed must be safely generated off-line and securely kept. In a Linux shell prompt this is done with the following command:

cat /dev/urandom |tr -dc A-Z9|head -c${1:-81}

For Mac users:

cat /dev/urandom |LC_ALL=C tr -dc 'A-Z9' | fold -w 81 | head -n 1

/dev/random generates pseudo-random numbers by gathering environmental noise from device drives, network packets, etc. into an entropy pool from which the seed is generated.

While there are online seed generation tools, it is highly recommended that you avoid these. There have previously been phishing websites which masqueraded as tools that have stolen users seeds.

The generated 81 character long string consisting of A-Z uppercase letters and the number 9. All private keys and sets of addresses bundling transactions derive from the original seed in a stream-like manner (somewhat similar to mnemonics in Ethereum wallets).

Once a send transaction is done from an address that address should never be reused as each output reveals part of the private key. Receiving outputs can be pooled in a single address, but once that address is spent from it should be emptied and it shouldn’t be reused for either sending or receiving. The seed is not compromised if funds are received in a spent from address, but the funds are.

This is due to the quantum-resistant cryptographic scheme adopted by IOTA. One-time signature schemes (and one-time cryptographic hash functions in particular) are methods for constructing digital signatures using one-way functions. Similar in principle to one-time pads and, as the name implies, this works by using key pairs only once. In essence, once bits are looped they must afterwards be consumed.

This minor, early-phase inconvenience and seemingly technical barrier to participation is soon to be resolved with the upcoming release of the Trinity wallet (currently in alpha testing phase). This is intended to provide a user-friendly and intuitive cross-platform interface to the tangle and a module for the seed and address handling logic offering a smoother user experience.

Transactions, Bundles and Snapshots



Image via Fotolia

A transaction on the tangle consists of an encoded 2673 tryte string which decodes an object containing address, signature, value and tag attributes. Transactions are usually grouped in arrays called bundles which wrap together value transactions containing outputs to receiving addresses and inputs to spending ones. Value transactions as such require that inputs are signed.

As the database of transactions grow, periodic snapshots are performed which group non-zero balances together. These are stored into a single record and the rest are shed off. The addresses with non-zero balances serve as new genesis addresses in a way, with no previous history attached.

Presently, under coordinated mode of operation, snapshots are done manually by the foundation. The foundation is building a solution whereby the process will be automated in the near future and permanodes placed for retaining the entire history of the tangle.

Services such as thetangle.org and the Oyster network (which stores data on the tangle by reattaching it and performing PoW) presently can be considered to serve as permanodes. Any valuable data can be preserved on the tangle by coupling it with a few iotas or otherwise staking some value into the system.

Alternatively, specialized nodes which store only contextually relevant data or transactions flowing through their neighborhood segment of the tangle can also be put in place.

Coordinated Consensus Mode and Milestone Transactions

The Coordinator (or Coo for short) are IOTA nodes spread across the globe and operated by the IOTA foundation. These serve the purpose of issuing zero-value transactions (called milestones) which ensure the incoming transactions that reference the milestone ones conform to the rules of the protocol.

This will set the direction for tangle growth by coordinating the steps. Participating nodes for their part also verify that the Coo is not breaking consensus rules by creating iotas out of thin air or approving double-spendings.

The purpose is as a temporary safeguard for the network in its stages of infancy to avoid against larger scale attacks. When the volume of organic activity on the tangle reaches a sufficient threshold for it be self-sustainable, the Coordinator will be shut off. The tangle will then switch to ensuring consensus via Monte Carlo Markov Chain random walks.

Setting Up A Basic Node (IOTA Reference Implementation)

To set up a node one needs an optimal configuration. Below are some of the minimum recommended hardware / software:

8 to 12GB RAM

25GB storage

dual core CPU

24/7 Connectivity

Either Ubuntu (16 or 17) or CentOS is preferable

A VPS (Virtual Private Server) running in a data center is a common and convenient solution and there are a number of VPS hosting providers to use.

After getting access to the server (IP address and user password), log in remotely via command-line (or PuTTY in Windows):

$ ssh your_username@IP.address.to.server

Enter password, and if user isn’t “root” (Contabo servers are by default root) make sure you have “sudoer” privileges and execute “sudo su” to log as root. After that, simply run:

$ bash <(curl -s https://raw.githubusercontent.com/nuriel77/iri-playbook/master/fullnode_install.sh)

This fetches a deployment script which will automatically detect system parameters, download the necessary software packages and their dependencies. Make sure, during installation, to enable the Nelson and Field – modules on top of the core protocol. This will fulfill different responsibilities important for building a healthy network.

After successful installation, you will be presented with the URLs at which the peer manager and the Grafna dashboard (monitoring CPU I/O usage) are located. Peer manager is typically IP at HTTP on port 8811 and Grafna interface at port 555 and /dashboard/db/iota?refresh=30s&orgId=1 (default username “iotapm” and password as provided during installation)

These provide remote interface access to node statistics and health metrics without the necessity to log in directly to the remote server via ssh.



Grafna login screen



Grafna monitoring in Browser



Grafna Price Data

Next, in the running ssh console to the remote VPS, run the following to enter your node’s GUI configuration interface:

$ iric



IOTA Reference Implementation Configuration Manager

After downloading the fully synchronized database (“Get Fully Synced DB”), we go on to enable Nelson.

Nelson Auto-Discovery Peer Manager

The basic IRI is usually bound to a structured overlay network of neighbors in the tangle. This is done via a JavaScript wrapper called “Nelson”. Nelson acts as a gatekeeper and network overseer responsible for discovering peers, negotiating connections, load balancing traffic and protecting against bad actors.

Each Nelson node maintains a list of trusted peers and has a “personality” which changes over intervals of time on the tangle called “epochs”. These last between five to ten minutes. This means incoming contacts may not be immediately accepted depending on a number of parameters and factors. As more contacts are earned, trust accumulates, the weight of which is a fundamental metric in how the tangle operates.

Bolero is a similar cross-platform implementation which is easier for Windows users and spawns the whole full node setting with a single click. This has recently been integrated (but not fully so) with Nelson and Field.

After we’ve enabled Nelson, we next go on enabling Field.

CarrIOTA Field

CarrIOTA is a public load balancer for optimizing node performance and resource usage to the benefit of the whole network. It provides protection against DDoS attacks and a layer of hardened security for critical applications. Additionally, it computes statistics and provides health metrics for an IRI and its neighbors which serves as valuable data for further building of applications and integrating various instances.

CarrIOTA Field also functions as an incentivizer which significantly speeds up transactions within it, stabilizes the tangle as a whole. It also distributes weekly IOTA token donations among participants doing Proof-of-Work (the simple Hashcash type PoW, not the Bitcoin miner kind).

Upon enabling Field from the configuration GUI one needs to enter a unique identifier (any string) and an address for receiving the weekly distributed donations. The output of a generated seed as explained above should have the following form:

QAZEEELQCKLVOORDUBXTCLNDBQYMYHLTCADJSUVXBAYWHZXBHACHUBQWQONZHGUJOKWSOXKGEOIPSSUML

The seed is entered in the wallet after which a generated receiving address is copied and pasted in the address field in the configuration GUI.



The currently used IOTA wallet

Lastly, we need to enable Proof-of-Work for Field to pass attachToTangle jobs to the IRI full node, so we go to “Configure Files” and enter “Field”.



Configuration Setup

Line “pow” must be changed from “false” to “true”, Ctrl+O to save and Ctrl+X to exit. This can also be done from the command line with:

field --pow --address IOTA_ADDRESS

We now go to http://field.carriota.com/ and use our provided identifying string to check if the node is present on the tangle in Field. This can alternatively, can be searched for in the plaintext file at http://field.carriota.com/api/v1/graph.

If the correct ports were not enabled during the installation, then open the following ports in the NAT router:

UDP: at 14600 (many neighbors want to use just UDP as a fast, lightweight network packet)

at 14600 (many neighbors want to use just UDP as a fast, lightweight network packet) UDP: at 15600

at 15600 TCP: at 16600

at 16600 TCP: at 21310 (for CarrIOTA Field)

Donation funds are dispersed to the provided donation addresses of the participating nodes in a 48 hour interval after a season ends. A total of over 3.4 billion iotas have been paid out in the beginning of March as disclosed in the below tweet by an IOTA researcher.

#CarrIOTA #Field donations are out with two bundles of epic proportions:https://t.co/3lhAabLtL2https://t.co/QcaiKZGn6s over 3.4 billion #IOTA have been paid out. Thanks to everyone for participating! — Roman Semko [DevIOTA] (@RomanSemko) March 9, 2018

Perhaps more importantly for adoption, the number of participating nodes has also quadrupled since.

Additional Resources and Information

Pending transactions can be manually reattached via a python script ran from the command line of the node after fetching the official IOTA python libraries post-installation.

apt-get install python-pip -y && pip install --upgrade pip && pip install pyota

After this, one needs only run “reattach” from the command line.

$ reattach

A number of basic Web-based tools (such as various binary to ternary converters, current Field statistics, database size, etc.) are accessible at Tangle Tools and a small collection of tutorials can be found here.

ChainLink’s Linkpool have also released an IOTA adaptor for ChainLink Oracle nodes recently and other such oracle services as the XYO geolocation oracle appear to have IOTA integration as priority in their roadmap agenda.

Other IOTA-based projects under development include machine learning as a service, an IOTA payment gateway, various ‘tangled’ chat applications and many more.

For keeping up with updates and announcements and participating in discussions, or plain seeking to better understand the dynamics of the tangle and ask questions, IOTA’s official Discord houses a large and active community of people working on developing applications and collaboratively building projects on IOTA. An official community forum has also been recently launched.

How Much can You Earn?

While running an IOTA node can be an interesting exercise that benefits the broader ecosystem, you are no doubt interested in the returns that you can earn. You do, after all, have to meet the cost of running the VPS and remunerating your time for maintaining it.

This will depend on a number of factors. These include the the demand on the network, competition, the server configuration and of course the price of MIOTA.

However, at current levels one could expect to earn anywhere between 12-15 MIOTA per month for running the node. If you were to go with the most simple configuration on a VPS, monthly fees are about $8. This means, at current prices, you are earning at least $8.

Assuming all remains equal, that means that you are earning about 100% on your investment per month. Of course, you could always hold onto the MIOTA you have as profit. If you long term positive on the IOTA ecosystem then this will no doubt serve you well…

Featured Image via Fotolia