IOTA Whitepaper - Tangle - Cryptocurrency for Internet-of-Things

IOTA Whitepaper - Tangle - Cryptocurrency for Internet-of-Things

Login to download
Currency
IOTA
Symbol
MIOTA
Founders
David Sønstebø, Sergey Ivancheglo, Dominik Schiener, Dr. Serguei Popov
Abstract
In this paper we analyze the technology used as a backbone of IOTA (a cryptocurrency for Internet-of-Things industry). This technology naturally succeeds the blockchain technology as its next evolutionary step and comes out with features required for micropayments conducted on a global scale.

Introduction
The rise and success of Bitcoin during the last six years proved the value of blockchain technology. However, this technology also has a number of drawbacks, which prevent it to be used as a one and only global platform for cryptocurrencies. Among these drawbacks, an especially notable one is the impossibility of making micro-payments, which have increased importance for the rapidly developing Internet-of-Things industry. Specifically, in the currently available systems one must pay a fee for making a transaction; so, transferring a very small amount just makes no sense since one would have also to pay the fee which is many times larger. On the other hand, it is not easy to get rid of the fees since they serve as an incentive for the creators of the blocks. It should be also observed that existing cryptocurrencies are heterogeneous systems with clear separation of roles (transaction issuers, transaction approvers). Such systems create unavoidable discrimination of some of their elements which in turn creates conflicts and makes all elements spend resources on conflict resolution. All this justifies a search for solutions essentially different from the blockchain technology, on which the Bitcoin and many other cryptocurrencies are based.

In this paper we discuss a blockchainless approach, which is currently being implemented in IOTA, recently designed as a cryptocurrency for the Internet-of-Things industry. Of course, any theoretical analysis would be incomplete without feedback from a working version of such a system; we hope that soon such a feedback would be available.

In general, IOTA works in the following way. Instead of the global blockchain, there is a DAG (directed acyclic graph) that we call tangle. The transactions issued by nodes constitute the site set of the tangle (i.e., the tangle graph is the ledger for storing transactions). Its edge set is obtained in the following way: when a new transaction arrives, it must approve two1 previous transactions; these approvals are represented by directed edges. If there is no directed edge between transaction A and transaction B but there is a directed path of length at least two from A to B, we say that A indirectly approves B. There is also the “genesis” transaction, which is approved (directly or indirectly) by all other transactions. The genesis is described in the following way. In the beginning there was an address with balance containing all the tokens. Then the genesis transaction sent these tokens to several other “founder” addresses. Let us stress that all the tokens were created in the genesis (no other tokens will be created), and there no mining in the sense “miners receive monetary rewards”.

A quick note on the terminology: sites are transactions represented on the tangle graph. The network is composed by nodes; that is, nodes are entities that issue transactions.

Now, the main idea is the following: to issue a transaction, users must work to approve other transactions, therefore contributing to the network’s security. It is assumed that the nodes check if the approved transactions are not conflicting and do not approve (directly or indirectly) conflicting transactions. As a transaction gets more and more (direct or indirect) approvals, it becomes more accepted by the system; in other words, it will be more difficult (or even practically impossible) to make the system accept a double-spending transaction. It is important to observe that we do not impose any rule for choosing the transactions to approve; rather, we argue that if a large number of other nodes follow some “reference” rule (which seems to be a reasonable assumption, especially in the context of IoT, where nodes are specialized chips with pre-installed firmware), then for any fixed node it is better to stick to a rule of the same kind.

More specifically, to issue a transaction, a node does the following:
  • First, it chooses two other transactions to approve (in general, these two trans- actions may coincide), according to some algorithm.
  • It checks if the two transactions are not conflicting and do not approve conflict- ing transactions.
  • For the transaction to be valid, the node must solve a cryptographic puzzle (which may be computationally demanding) similar to those in the Bitcoin mining (e.g., it needs to find a nonce such that the hash of that nonce together with some data from the approved transactions has a particular form, for instance, has at least some fixed number of zeros in front).
It is important to observe that, in general, we have an asynchronous network, so that nodes do not necessarily see the same set of transactions. It should be noted also that the tangle may contain conflicting transactions. The nodes do not have to achieve consensus on which valid transactions have the right to be in the ledger (all of them can be there); but, in case there are conflicting transactions, they need to decide which transactions will become orphaned (that is, eventually not indirectly approved by incoming transactions anymore). The main rule that the nodes use for deciding between two conflicting transactions is the following: a node runs the tip selection algorithm many times, and see which transaction of the two is more likely to be (indirectly) approved by the selected tip. For example, if, after 100 runs of the tip selection algorithm, a transaction was selected 97 times, we say that it is confirmed with 97% confidence.
Let us also comment on the following question: what motivates the nodes to propagate transactions? In fact, in our setup the nodes do not have motivation not to propagate. Every node calculates some statistics, one of which is how many new transactions are received from a neighbor. If one particular node is “too lazy”, it will be dropped by its neighbors. So, even if a node does not issue transactions (and hence has no direct incentive to share new transactions that approve its own one), it still has incentive to work hard.

In the subsequent sections, we discuss algorithms for choosing the two transactions to approve, the rules for measuring the overall transaction’s approval, and possible attack scenarios. Also, in the unlikely event that the reader is scared by the formulas, (s)he can jump directly to the “conclusions” part in the end of corresponding section.

It should be noted that the ideas about usage of DAGs in the cryptocurrency context were around for some time. Specifically, the work introduces the so-called GHOST protocol, which proposes a modification of the Bit- coin protocol by making the main ledger a tree instead of the blockchain; it is shown that such a modification permits to reduce the confirmation times and improve the overall security of the network. In the paper the authors consider a DAG-based cryptocurrency model; differently from our model, the sites of the DAG are blocks (not individual transactions), the miners compete for transactions’ fees, and (as in Bitcoin) new tokens may be created. Also, observe that in the work a solution somewhat similar to ours was proposed, although it does not discuss any particular tip approval strategies. We mention also another approach that aims to make Bitcoin micro-payments possible by establishing peer-to-peer payment channels.
Author
evo
Downloads
1
First release
Last update
Rating
0.00 star(s) 0 ratings

More Resources