IOTA Report: Decoding the Tangle Part 3
- Post by: bag2q
- March 11, 2018
- Comments off
The Tangle vs IOTA — Comparing theory and practice
IOTA Report: Overview
Part 2 focuses on the history of the team, token and protocol: IOTA Report: Decoding the Tangle Part 2.
In Part 4, we question the current implementation of the network’s usability, and examine the future plans of the IOTA network: IOTA Report: Decoding the Tangle Part 4.
In this article (Part 3) we contrast the technological promises of the Tangle, as outlined in the Whitepaper, against the current practical implementation of the IOTA protocol:
Summary / TL;DR
- The Tangle is a theoretical concept which aims to overcome the current challenges of blockchain systems.
- There is a clear differentiation between the concept of the Tangle and the practical implementation of the IOTA protocol.
- In the Whitepaper, there is no mentioning of the Coordinator Node, Milestones or Snapshots, which are all current features of the IOTA protocol.
- Full Nodes in IOTA store the history up to the latest Snapshot.
- Light Clients in IOTA rely on Full Nodes to interact with the network.
- Milestones are transactions by the Coordinator, a Full Node operated by the Foundation, which are treated as valid by all other Full Nodes in the system.
- Snapshots are events triggered by the Foundation which delete all zero balances in the system and restart the Tangle from a ‘new Genesis’.
- Snapshots are similar to finalized blocks in a blockchain network, with the difference being that their creation is currently done by a centralized party instead of a distributed network of miners.
- The current implementation of the Tangle exhibits highly centralized characteristics as Milestones and Snapshots are performed by the IOTA Foundation itself, providing them a high level of control over the system.
Part 3: The Tangle vs IOTA — Comparing theory and practice
The aim of this article is to present an analysis of the IOTA protocol in its current implementation and compare it to the theoretical concept of the Tangle. The reason for doing this, is that the Tangle, as described in “The Tangle” Whitepaper, differs significantly from the live IOTA protocol deployed by the Foundation, leading to a confusion within some parts of the community regarding which features are actually currently deployed and which characteristics of the protocol are yet to be conceptualized.
The Tangle is a theoretical concept which aims to overcome the current challenges blockchain systems have in order to provide an outlook of how a protocol can be designed to fulfil the requirements of the upcoming Internet of Things industry.
At the beginning of the Whitepaper, it is explicitly stated that the theoretical vision and the current design of the Tangle are two completely different things:
“The purpose of this paper is to focus on general features of the tangle, and to discuss problems that arise when one attempts to get rid of the blockchain and maintain a distributed ledger. The concrete implementation of the iota protocol is not discussed.” (Whitepaper, p.2)
The Tangle, as described in the Whitepaper, aims to provide a framework for conducting trustless and feeless transactions in a highly scalable manner on a decentralized, partition tolerant network, consisting of potentially millions of IoT devices.
However, in practice, the actual implementation of the IOTA protocol currently fails to live up to most of these promises. Firstly, the protocol is currently not decentralized, nor trustless. It contains several centralized features such as relying on a Coordinator Node to provide trusted Milestone transactions that others treat as valid. Moreover, the system relies on Snapshots which are conducted by the IOTA Foundation, to prune the state of the Tangle in order to prevent the network from growing too large, as it is currently not suitable for large scalability. As we outline the implementation of the IOTA protocol and compare it to the theoretical concept of the Tangle, we will give a more detailed introduction of the terminology.
Nodes in traditional Blockchain Protocols
Broadly speaking, in traditional Blockchain protocols like Bitcoin & Ethereum, there are 4 major types of participants (or Nodes) interacting with the network (ignoring Listening Nodes):
Miners aim to be the first to create the newest block by solving the PoWproblem set and propagating its solution to the network in order to get a financial reward. In theory, they only need to store the last block of the network in order to fulfill this task.
Full Nodes on the other hand store the entire history of the blockchain and are therefore able to verify all transactions leading up to the Genesis block. A miner can operate a mining software + a Full Node, however is not required to do so. Operating a Full Node means that one is independent of the large mining pools, as one can reject invalid blocks that did not follow the required consensus algorithm, even if those are based on the longest chain, which other Nodes that do not store the entire history will follow.
Pruned Node have verified all previous transactions, however deleted blocks below a certain hight to save storage space on its local machine. It is almost useless for the community, however great for individuals which aim to only have limited storage capacities while still being able to verify new blocks.
The last type are Light Clients, which are capable of sending and receiving transactions, however they do not store the history of the network locally and hence rely on the network as a whole to provide them with the correct state of the blockchain. In Ethereum, Light Clients “download block headers by default, and verify only a small portion of what needs to be verified”.
In the DAG based Tangle Network, outlined in the IOTA Whitepaper, Nodesare described as “entities that issue and validate transactions” (WP, p.2). Hence no explanation is provided how different participants actually interact with the network.
In the practical IOTA implementation, however, a clear differentiation plus a special type of Node, called a Coordinator, exist, which will be further outlined below:
Nodes & Special Transactions in the IOTA Protocol
In theory, full nodes store, update and verify transactions from the last Snapshot, which occur roughly every month. As the IOTA network is asynchronous, a full node individually does not need to store the global state of the Tangle, collectively however, the network forms the IOTA Tangle. A full node is responsible for propagating transactions to neighbouring nodes.
Similar to Bitcoin or Ethereum, there is no direct monetary incentive to operate an IOTA full node. Therefore, running a full node is done mostly for altruistic or security reasons. Full Nodes enable IOTA users to verify transactions that go beyond the latest milestone up to the latest Snapshot. If the users trust that all Snapshots in the past were done correctly, they can have certainty that they are only verifying valid transactions.
In the future IOTA plans to incentives full nodes to store the entire history of the Tangle (beyond Snapshots) through a concept called Permanodes, which we will discuss in the next article.
Light Clients are devices that rely on the full node network to interact with the Tangle. However, there is no reference to any state storage. Without access to the Tangle, tip selection would not be possible. Therefore, when light clients, such as IoT devices & end-user wallet softwares, interact with a full node to run a tip selection algorithm, they only have access to the part of the Tangle which that specific node has stored. Hence, light clients run the risk of interacting with a malicious node propagating false transactions to the network. Therefore, one incentive to run a Full Node is not having to rely on other Nodes run by a unknown party to transact on the Tangle, especially when dealing with IoT devices that require 100% reliance that their transactions get accepted by the network.
The Coordinator & Milestones
A third type of node that is currently transacting with the IOTA protocol is the Coordinator. As mentioned by Co-Founder Dominik Schiener, the IOTA protocol currently “relies on a Coordinator”, which is a special type of Full Node operated by the IOTA Foundation, that issues a transaction (called a Milestone) roughly every one to two minutes which according to the Foundation, only references valid transactions. All nodes running the official IOTA software recognize the Coordinators signature and treat all transactions referenced by it as valid.
Hence a Milestone can be though of as a special transaction published by the Coordinator. It aims to shorten the number of transactions Light Clients have to verify in order to keep the Tangle from branching out too widely, which could result in different states of the ledger being present at certain ends of the Tangle simultaneously. It does so by pulling branches back to the main tangle, resolving potential double spends in the process and preventing the system from experiencing inconsistency.
Therefore, a transaction on IOTA is only treated “as a confirmed transaction”, if it is directly or indirectly referenced by a Milestone. This reduces the amount of computation required by the rest of the nodes in the network to validate transactions. The tip selection algorithm performed by the Coordinator when publishing milestones is not disclosed. The IOTA Foundation states that the milestones are necessary as a “mechanism to provide 34% attack protection” until the network is large enough. An official statement to when the network reaches this critical size to run without the Coordinator is yet to be announced.
The Foundation states that the long term goal is to transition to a protocol without the need for a Coordinator to ensure decentralization of the network. However, until that happens, the current implementation of the Tangle exhibits highly centralized characteristics, as the IOTA Foundation remains a single point of failure for the IOTA network.
Another feature that is employed by the IOTA protocol and not discussed in the Tangle Whitepaper are Snapshots, which are used every few months by the IOTA core development team to prune the size of the network. The Snapshot saves all non-zero balances and deletes all zero value addresses.
This effectively acts as a new genesis from which the Tangle can expand again. The reason behind performing Snapshots is to keep the network lightweight and reduce the size of the state. This is conceptually similar to a block in traditional blockchain system, representing a ‘finalized’ state. These Snapshots provide benefits to Full Nodes, as they do not need to store the history of the entire Tangle. This however comes at the cost of auditability, as regular participants cannot see the entire history of the network back to its Genesis (a problem we discussed in Part 2).
Snapshots are therefore very similar to finalized blocks in a blockchain network, with the difference being that their creation is currently done by a centralized party instead of a distributed network of miners.
The IOTA Foundation, being the centralized body consisting of a few individuals, is solely responsible and able to take these Snapshots, which again underlines the current problem of the network not being decentralized, but relying on a few individuals to prevent it from expanding to wide, which would result in the network being vulnerable to a variety of attacks.
In any case, the major challenges the IOTA network is facing deals with removing its reliance on a single point of failure, being the IOTA Foundation itself. The IOTA protocol currently relies on Milestones to secure the network, which are issued by a Coordinator Node using an unknown tip selection algorithm. Snapshots, conducted manually by the Foundation, delete the history and therefore eliminate auditability. Full Nodes altruistically host the history of the Tangle, up until the most recent snapshot. In order for the IOTA protocol to achieve the promises of the Whitepaper, that is a truly decentralized, and scalable IoT network, it has several obstacles to overcome.
The roadmap on how the Foundation plans to do just that will be further discussed in the next report.
To conclude our report series, we are going to evaluate the current applications and the future implementations of IOTA. We will also analyze controversies around the IOTA Foundation and give an overall evaluation and considerations on the Project.
At Konfidio we have composed a detailed report on the IOTA project: we provide a condensed but informative four-part summary on Medium, aimed to give an overview of IOTA for entrepreneurs and companies that are planning to build on the protocol, as well as for developers and crypto-enthusiasts that are interested in the Tangle.
What is Konfid.io?
Konfidio is a technology consultancy and venture studio based in Berlin that focuses on Blockchain technology to build decentralized applications in private as well as public distributed systems. We constantly research the practical usability of distributed ledger projects and like to share our findings with the wider community.
Disclosure: Dr. Mervyn G. Maistry, CEO & Founder of Konfid.io, is an early supporter of DLTs since 2014 and a strong believer in the potential of DAGs as a technology. He was an advisor to IOTA and personally to Dominik Schiener and David Sonstebo, advocating for setting up a transparent and corruption-free foundation in Germany and introducing them to a number of Fortune 500 and Dax 30 clients . Since June 2017, there has been no communication and no business relationship between Dr. Mervyn G. Maistry and the IOTA foundation, its founders or any of its functionaries.