IOTA TRANSACTION APPROVAL PROCESS

Welcome back to our series covering the essential elements of IOTA, a crypto network designed specifically for use with IoT (Internet of Things) devices. In the past few posts we’ve spent time discussing tip selection on the tangle. If you weren’t there, feel free to take a few minutes and read Part 1, Part 2, and Part 3.

To quickly recap, a tip is an unapproved transaction that exists on the tangle. Every time a node wants to exchange MIOTA, it must first approve two transactions that already exist. To sum up what we learned in the last few posts, a weighted random walk is utilized to ensure that the tangle continues to scale correctly and continues to converge even as more and more nodes participate in the network.

So that gets us to our topic for this post: approval. It’s important to understand from the outset that even though a transaction may be approved it’s not necessarily wise to trust that it is 100% confirmed quite yet. We’ll get to confirmation soon, but for now we’re just going to look at the simple act of approving a transaction. If you are familiar with other cryptocurrencies, you may understand the reason behind this; for those of you who may be new to the crypto world, let’s discover what’s going on here.

One quick thing: where did the tokens that are currently in the network come from? IOTA isn’t like Bitcoin where more and more tokens are being placed on the network over time. The genesis block of IOTA contained all of the tokens that will ever exist on the network. After a bit of trading took place by the creators of the network, the tokens entered and began to be used as a monetary exchange.

Approval Example

Alright, let’s talk about our friends Alice and Bob (two fictitious characters who are commonly used in discussions about crypto). Alice owes Bob some money for lunch last week, so Alice decides to pay Bob in IOTA. Alice transfers Bob 5 IOTA from her account to his. That’s great, but Bob needs confirmations from other nodes on the network before he can assume that his exchange with Alice made it through properly. Another user, Ted, decides to transfer IOTA to someone on the network.

Remember that to do so, he must randomly pick a transaction on the tangle to approve (using the weighted random walk that we discussed in part 3 of tip selection). Ted chooses to approve Alice’s transaction, but to do so, he needs to start at the genesis block and enumerate every transaction that either directly or indirectly approved Alice’s transaction with Bob.

There are a variety of ways that Ted could eventually reach the account balances present in the transactions and the amount of currency transferred (since the network may have multiple paths from the genesis block to Alice and Bob’s exchange). What’s important though is the assurance that none of the transactions allowed for spending more than Alice had in her account at any time (such that her balance became negative). Another important facet in correctly sending her IOTA is that Alice never double spentany tokens. A double spend occurs when a node attempts to send the same tokens twice to either the same or two different nodes. This is never allowed (in any cryptocurrency for that matter, not just IOTA).

Correct And Incorrect Transactions

You might be thinking, “Why does Ted care if the transaction was correct or not? Can’t he just approve it and move on?” Here’s why: if Ted approves a transaction that turns out to be incorrect, his transaction will be linked to a branch that will receive very little consensus from the network, eventually being abandoned in favor of a branch with more trustworthy transactions.

This means that Ted has a vested interest in ensuring that everything works prior to the transaction he approves so that his own transaction will be accepted by other nodes in the network and allow for the proper exchange of his own IOTA. Things tend to become more serious when our own money is on the line!

Okay, so Ted approved Alice’s transaction since it was, indeed, valid. Not only did she have enough IOTA in her wallet, she also never dipped below a value of 0 IOTA nor did she attempt to spend the same tokens twice. So now since it has an approval, Bob can place high confidence in it, right? Eh, not so fast. Let’s talk about the notion of confirmation confidence.

As more and more nodes approve our transaction, we become increasingly confident that the results in it are trustworthy. The tangle has an algorithm for computing confirmation confidence. Essentially, the tip selection algorithm (remember the weighted random walk?) is performed 100 times. The number of tips out of 100 that approve our transaction is called the confirmation confidence in percent (say 99/100 tips approve – this would be a 99% confidence). There’s no magic number that declares a transaction to be “fully trustworthy”, but the higher the confirmation confidence grows, the more likely you can be to trust that it is, in fact, a transaction that you can trust.

IOTA Transaction Confirmation Simulation

Luckily the folks over at the IOTA Foundation have put together another very interesting and informative simulation to help grasp the concepts we’ve been discussing. Go ahead and open the link, and let’s take a quick look at confirmation confidence in action. Before changing any settings, hover your mouse/pointer over the various transactions on the network. You’ll see the Cumulative Weight and Confidence appear in a pop-up box. Remember that in a weighted random walk, a higher weight lends more credence to that path being chosen by other nodes as they walk across the tangle.

The confidence shows how much this transaction can be trusted based on those direct approvals (in blue to the right of the chosen box) and indirect approvals (in red to the left of the chosen box).

Take a few minutes to change some of the sliders at the top of the simulation – notice what happens as more nodes are added or taken away from the tangle. It’s interesting to see that tips have a confidence of 0 while other transactions can possess up to a 1.0 confidence based on the number of direct and indirect approvals. (Note that technically the 1.0 confidence is rounded up by truncating decimal points; a true confidence asymptotically approaches 1.0 but never fully reaches it if you’re willing to stretch the decimal points out far enough).

Practical Use Cases For IOTA

Before we wrap up, let’s discuss a practical implementation currently employed by the IOTA Foundation. IOTA was designed to run in a fully decentralized, autonomous manner. There’s not supposed to be any interventions by the network operators; however, the network is still at a point in its growth that there must be some intervention for a little while in order to ensure that it can scale, grow, and be considered reliable.

This is due to the fact that double spending, while very unlikely, could still be possible if a node decided to completely overwhelm the network with transactions. This is similar in nature to the Bitcoin 51% problem – if a single node were to gain 51% or more of the hashing power on Bitcoin’s network, it could wreak havoc and cause grave damage to the other nodes on the network.

So how does the IOTA Foundation work to curb this behavior presently? They incorporate the coordinator, which utilizes milestone transactions. At two-minute intervals, a milestone transaction is placed on the tangle; any transaction approved by the milestone is considered to have 100% confirmation confidence immediately. This means that a double spend attack becomes impossible since only one of the original transactions can be approved, thus effectively eliminating the “double” part of the double spend.

Coordinator Removal

When will the coordinators be removed from standard operation on the network? That’s still left to be determined. The network needs to be at a scale large enough to ensure that no node would be able to overwhelm the network with enough transactions per second (IOTA’s equivalent of hashing rate in the Bitcoin network). Although IOTA is growing as a viable crypto offering, it’s just not quite sizable enough yet…hence the presence of coordinators. Once the ubiquity of IOTA allows for robust operation, the IOTA Foundation has promised to remove the coordinators. This will enable the network to run even more efficiently and effectively than it does currently.

Approval Process Recap

In summary, a node can exchange IOTA with another node on the network after approving two other transactions. Currently, there are safeguards in place to ensure that malicious actors don’t attempt to overwhelm or overtake the network; these safeguards will be going away after the network has grown to a size that will render these attacks infeasible. Interested in learning more? Check out a few of these articles:

Learn more about the approval process in the network and how double-spends are thwarted.
Confirmation confidence and the current implementation of coordinators dominate this post.

Thanks so much for reading, we’ll see you in the next post!