Gone are the days of IRI and a basic GUI light wallet. With the project’s scope now in clear view, it’s imperative that the learning curve remains smooth enough for newcomers.
If the research team felt it necessary to release a terminology guide for coordicide last week, then it’s necessary to release a terminology guide for all of IOTA this week.
Technical debt, aka piled up old code, is cited as one of the reasons for moving away from IRI. It’s important to realize that the relationship between confusing-jargon:unproductive-newcomer is equivalent to the relationship between technical-debt:unproductive-developer. “IRI” has been mentioned twice already … don’t worry if you’re not entirely sure what that means, because this is exactly what we’ll be exploring.
The Basics
Schmucklos wrote a great article last month explaining IOTA from a high level. The article touched on data structure and transaction status, mostly focusing on features and other non-technical aspects of IOTA. After reading both that article and this section of the current article, we’ll have a solid foundation of IOTA’s basic terminology before moving on.
IOTA is a distributed ledger. In its most basic form, this means there must be some number of interconnected computers running IOTA software. These computers are called nodes, and each node holds a full copy of the ledger going back to the most recent snapshot. A slew of transactions are continuously being encrypted and sent across the network to be verified by neighbors. All of these transactions, being governed by IOTA software’s rules of interaction, naturally give rise to a data structure/network topology that’s commonly referred to as the Tangle. If a transaction adheres to the rules of the software, it eventually becomes what’s called confirmed.
It’s easiest to visualize the mesh of transactions that naturally arises from the rules of the IOTA system:
The dots are transactions while the connecting lines are references to other transactions – “nodes” and “edges” in graph theory. You’ve probably heard the term “directed acyclic graph” or “DAG” in association with IOTA. That’s the formal name of the type of graph that’s formed by IOTA transactions and confirmations.
Don’t confuse a node (transaction) in the Tangle (transactional topology) with a node (computer) in the IOTA network (collection of computers and their databases across the physical globe).
The Tangle network topology can be described as being woven together. David has said that the inspiration for the IOTA logo was imagining looking down a rope lengthwise after it had been transected. Imagine you’re looking down a rope lengthwise when you look at the logo below:
IOTA nodes (computers) brought online in 2016 were running the first version of IOTA’s software called the IOTA Reference Implementation. That’s why you see “IRI” talked about so much around the time of software updates – because IRI is the software that computers are running to maintain the Tangle. The software is written in a programming language called Java, which has its own pros and cons that developers love to debate. IRI v1.8.6 is the last release.
Anyone with a computer or server who installed IRI and connected with a few other computers also running IRI could participate in the Tangle. This was an acceptable solution for the more technical users who were comfortable with the command line, but the general population isn’t in such a position. So, cries for an easier way to interact with the Tangle (sending transactions, messages, connecting to nodes, etc.) grew in volume going into 2017.
In early 2017, the IOTA Foundation released the first GUI (“graphical user interface”) Light Wallet. This made it easy for non-programmers to install wallet software and interact with the Tangle for two reasons:
- Previously, users were required to install IRI, start a node, keep their node online 24/7, and connect to a number of other nodes in order to interact with the Tangle. With the GUI Light Wallet, people could now connect to and send transactions by proxy through someone else’s pre-existing node, no longer needing to worry about maintaining their own full node.
- The “GUI” part. Logging into a node and making transactions via the command line is daunting for non-tech users. With this graphical user interface wallet, people could interact with the traditional graphical windows, buttons, and visuals they’re used to elsewhere on their computer.
2019 saw a complete overhaul of the GUI Light Wallet when the IOTA Foundation released the brand new Trinity Wallet. Simply, a new GUI wallet with more features and even better usability than the old GUI wallet.
Plenty of new terminology has sprung up since those days, but it almost exclusively pertains to concepts of envisioned future states of IOTA. We’ve established a good foundation of understanding already: Nodes, transactions, Tangle, IRI (Java), and GUI Light Wallet.
Temporary Measures
IOTA has always needed to balance its ultimate vision of achieving truly decentralized transactions with its ever-present requirement of retaining security in the current moment.
The Coordinator is IOTA’s solution to this balance, and is only a temporary measure. The Coordinator, or “Coo“, is a node run by the IOTA Foundation that sets milestones for the Tangle. It can be thought of as training wheels for the network. Without training wheels, the Tangle would be susceptible to falling over (analogous to being attacked). Training wheels ensure current network security while allowing IOTA to meander its way toward a final solution that doesn’t include the temporary Coo. All of the Foundation’s research resources have been put behind this goal of reaching a Coo-less end stage of development, a process now colloquially known as Coordicide.
Bridging the Gap
If IRI is “IOTA 1.0”, and the end-goal is to achieve Coordicide with “IOTA 2.0”, getting from here to there must traverse an intermediate stage called “IOTA 1.5”.
Chrysalis is the name of “IOTA 1.5”, and is so named because it describes the intermediate stage in the evolution of caterpillar to butterfly. Chrysalis is the subject of an entire section in the Roadmap, with multiple sub-components and terminology that we can delve into here.
- White flag approach: A new way of tip selection. It supposedly increases efficiency, increases speed, reduces need for reattachments, and even purports to eliminate certain kinds of attacks
- Autopeering: With older node software, nodes had to manually track down the IP addresses of potential neighbors. Autopeering removes the need for manual IP addresses
- Universally-random tip selection: Another improvement to tip selection
- UTXO model: Most excitingly promises to add support for colored coins, but also deals with conflict handling and invalid reattachments
- Reusable addresses: We’ll do another entire article on signature schemes. Suffice to say that the old signature scheme required that a new address be used after it’s spent from. This was always a large hurdle for new users and exchanges alike
- Milestone selection: Speeds up network confirmations
- Atomic transactions: Changes the bundle construct to reduce transactional load on the network
- Binary transaction layout: Eliminates the need for so many binary-ternary conversions
Instead of focusing on the minutiae of these bullet points, the takeaway is that Chrysalis is the name of IOTA as we move away from “IOTA 1.0” (IRI) and into “IOTA 1.5” (Chrysalis) to bridge the gap into an eventual “IOTA 2.0”.
The software used in “IOTA 1.0” was written in Java and called IRI. The software that’ll be used in “IOTA 1.5” (Chrysalis) will come in two different varieties: One is written in the programming language Go and called Hornet, and the other is written in Rust and called BEE. Hornet is a collaboration between the IOTA Foundation and an EDF-supported community project while BEE is solely an IOTA Foundation project.
The Hornet team launched version 0.4.0 and did some stress testing this week:
We thank everybody who participated in our last community stress test! #Hornet reached over 1200 TPS w/ a max stable confirmed transactions per second rate of 620 (CTPS). We expect higher limits w/out nodes de-syncing as we continue to integrate our 1.5 updates.#IOTA pic.twitter.com/X0Fq3nuY2L
— IOTA (@iotatoken) June 2, 2020
It looks like people are starting to get excited about the 1000% increase in throughput of comnet vs. mainnet at 10 seconds comfirmation time but let me tell you something: "You ain't seen nothing yet …"
IOTA is going to finally deliver on revolutionizing DLT.
— HusQy (@hus_qy) May 29, 2020
Remember that Hornet and BEE are merely software node implementations that themselves are small pieces of the larger Chrysalis stage of development.
This week’s Roundup summarizes the stages of IOTA development and ties them into actual business use cases. Try watching the Roundup again if you had trouble following along without a firm grasp of terminology the first time:
And IOT1 Academy came up with a sleek graphic to explain the stages:
End Game
It’s best to leave Coordicide terminology, “IOTA 2.0” terminology, and various research terms for another day. These topics all refer to a future implementation of a technology still under active research anyway. The expectation is that this terminology will remain in flux as the researchers progressively invent the language to describe their new findings as they go. Being armed with nomenclature surrounding “IOTA 1.0/IRI”, “IOTA 1.5/Chrysalis”, the Chrysalis node software Hornet and BEE, and where these stages fit in the big picture is a great start toward smoothing the IOTA learning curve.
