IOTA Implementations
Currently, on the one side all Full Nodes run the IOTA Reference Implementation in order to maintain the Tangle in an distributed manner, and on the other side the official IOTA wallet uses these Full Nodes to access the Tangle for receiving and sending transactions. In future, we might see additional implementations providing the same APIs.
The Full Nodes are the entry points into the IOTA network. They are providing interfaces for reading and extending the Tangle; their most important tasks are:
- Adding transactions to the tangle
- Checking whether transactions are valid
- Exchanging transactions with neighboring Full Nodes in order to get a full view of the Tangle
Possible protocol adaptions in IOTA
If someone wants to introduce some protocol adaption, this has to be implemented in the software that is running on the Full Nodes. For examlpe, a Full Node may decide to run a software that requires the payment of a certain transaction fee for each transaction in order to process it. Then, the Full Node's behavior must be accepted by multiple parties. Namely, two requirements have to be satisfied:
- All IOTA users interacting with the Full Node, i.e. the ones sending and receiving transaction, must accept the behavior
- All neighboring Full Nodes must accept the behavior
If the first requirement is not met, the Full Node will not be able to serve IOTA users, which would make the Full Node obsolete. If the second requirement is not met, the Full Node will not be able to get a full view on the Tangle as information about transactions from other Full Nodes are missing, which in the end would make the Full Node obsolete, too.
Hence, future changes to the IOTA protocol are possible if they are adapted by "enough" IOTA users and "enough" Full Nodes. However, coming up with concrete numbers is a very difficult task. Statements about the required share of IOTA users and Full Nodes would require comprehensive simulations that rely on (a) knowledge of the Full Node infrastructure, and (b) the occurring protocol adaption behavior of both IOTA users and Full Node operators. As the detailed full node infrastructure by design is not fully known, and as there will always be a high uncertainty in the adaption behavior, only very rough estimates can be made (at some point a consensus may be reached, at some point a certain attack may be possible, at some other point some other attack may be possible, etc.).
Different kinds of IOTA protocol adaptions
In general, protocol adaptions can be separated into two major categories:
- Soft forks: Changes to the protocol implementation that are backward-compatible to the old protocol, such as a new field in a transaction which just can be ignored by old implementations
- Hard forks: Changes to the protocol implementation that are not backward-compatible
A soft fork change would still allow all IOTA Full Nodes, independent of whether they are upgraded or not, to maintain a collective consensus on the state of transactions in the Tangle.
A hard fork change would result in two options:
- All IOTA users and Full Nodes agree on the protocol upgrade, and the old protocol is not used anymore.
- Only a part of the IOTA users and Full Nodes follows the protocol upgrade, and the Tangle hence is split into two Tangles: Tangle-A with the transactions that have been added following the old protocol rules, and Tangle-B with the transactions that have been added following the new protocol rules. Theoretically, this could result in two coins: IOTA-A and IOTA-B, whereas the address balances at the time of the fork would be the starting point for the balances in Tangle-B.
Comparison with protocol adaptions in Bitcoin
In Bitcoin, we could observe hard forks already multiple times. As a result, in addition to the traditional Bitcoin we now have further Bitcoin blockchains/coins such as Bitcoin Cash (larger block size) or Bitcoin Gold (different hashing algorithm). For realizing protocol adaptions, Bitcoin usually uses polls where miners can indicate their adaption intention prior to a planned adaption via a flag in the header of their mined blocks (i.e. the miner community agrees to vote on whether a discussed protocol adaption should be realized or not). Based on the poll results, the miners can decide how they want to proceed.
For IOTA, the rather anonymous nature of the Full Node infrastructure seems to make it harder to agree on protocol changes in such a community-based manner.