Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permission-free manner. As IOTA expands, it is important that the right tools are available to support organizations and engineers looking to bring the machine economy to life.
Oracles provide blockchains with external information, typically for use in Smart Contracts, or provide interoperability between different distributed ledgers.
While oracles are primarily intended to be a bridge between the external / offchain world and decentralized networks and services, they suffer from the age-old “garbage in, garbage out” problem. If the data going into an Oracle can be manipulated or censored, it is possible that “wrong” data will lead to “wrong” results. Some Oracle solutions attempt to address this problem by ensuring that the Oracle uses inputs from a sufficiently large number of independent sources. Other Oracles on the market have proposed a set of standards to bring off-chain data to the chain, but they too suffer from inherent bottlenecks that can hinder real-world deployment.
The IOTA Foundation provides tools and frameworks to interact and develop on the Tangle. This includes different nodes, official wallets and standalone data-related products like IOTA Access or IOTA Stronghold.
IOTA Digital Assets (Colored Coins) are tokens that are based on IOTA and can be used to tamper-proof represent assets from the real world, like concert tickets, ownership of real estate, ownership of an asset or they could work as access tokens.
Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permission-free manner. Oracles provide DLTs with external information, typically for use in Smart Contracts, or provide interoperability between different distributed ledgers.
Smart Contracts were created to make the enforcement of a contract by third parties, such as a central authority, unnecessary. They enable the execution of trustworthy transactions which are traceable, transparent and irreversible.
Overview of the current and future wallets you can use to store, send and receive your IOTA Tokens.
Firefly is the successor of Trinity. It is designed for IOTA 1.5 (Chrysalis). Its core functions will later be extended by functions like tokenized assets, chat and contact management. The initial features build on Trinity’s existing feature set. However, there are some key differences:
Introduction of profiles and accounts. Profiles mean multiple people can use the app on the same device without access to each other’s wallets. Accounts mean that a user can separate their funds into different accounts, for example, a main account and a spending account.
Firefly also enjoys the many benefits of Chrysalis, including reusable addresses, 24-word recovery phrases and improved network performance.
Spark is a low-security, temporary web wallet, or “burner wallet”. The idea is that you use the wallet for small amounts of funds, for a short period of time, and then you “burn” it, wiping the seed and transaction history.
IOTA Stronghold is a collection of multipurpose libraries for secure management of passwords, personal data and private keys. It is a secure software library written in Rust with the sole purpose of protecting digital secrets from hackers and accidental leaks. Stronghold provides an encrypted, persistent database for performing cryptographic operations in a secure computing zone that can be distributed across multiple devices.
The developer-friendly high-level libraries integrate the IOTA protocol and serve as a reference implementation for those looking for inspiration or a benchmark. The low-level libraries have no notion of cryptocurrency embedded in them and can be used in their entirety without the high-level libraries. In other words, anyone from any industry can use them.
Main differences between Stronghold and other databases:
Stronghold records are “inherently encrypted” to mitigate offline attacks. With most other databases, you have to do the encryption yourself.
Stronghold allows you to perform operations on these stored digital secrets without exposing them to external processes, and prevents these secrets from ever being exported in decrypted form.
Multiple Strongholds can work as a network and communicate and collaborate in a permitted, decentralized way.
The IOTA Foundation aims to incorporate machines of all performance levels into the IOTA network: from microcontrollers to phones to servers. Some of these systems have minimal computing resources and no operating system of their own. Aside from microcontrollers, the IF also focuses on energy efficiency, high performance, and an excellent user and developer experience. Of the available language choices, the IF felt that Rust was the best fit.
Rust is a low-level system programming language and is so efficient that it does not require automatic garbage collection; in doing so, Rust operates at a high level of performance while maintaining high memory safety, providing similar performance to C and C++. Along with its well-integrated modern tools, Rust helps to work faster on IOTA designs while being more confident that the code is doing what the IF intended. Rust is a relatively new systems programming language, with many loyal fans in the developer community. It is a safer alternative to languages like C and C ++, as well as a faster alternative to languages like Python and Ruby.
The Bee Framework
Bee is a framework written in the Rust programming language for building IOTA nodes and tools that interact with the IOTA network. The final product is intended to be a highly modular collection of basic Rust-Crates* that can be combined and extended. To that end, the IOTA Foundation’s various libraries will also be merged into Rust-Crates. Bee will also enable foreign function interfaces (FFI) that can be used in higher level languages. These will form the basis for client APIs.
*Crates are the basic compilation unit of Rust code and can be considered libraries or projects.
Entering the IOTA developer ecosystem should be as easy as possible so that people can use the Bee framework to contribute, extend, and build their ideas for the IOTA network. Bee will provide a central reference implementation of key data structures and algorithms that will be verified and eventually certified. Through this approach, improvements in all core components are expected to quickly propagate to all other libraries built on top of them. This will prevent any future implementation from having to be fixed or corrected.
The IOTA Foundation wants to enable machines of all performance levels to join the network, from microcontrollers and single-board computers to phones, web browsers, desktop machines and servers. To do this, the Bee component libraries are to be implemented from scratch. Each library can be imported individually to have as few dependencies as possible. With microcontrollers in mind, these libraries should not rely on runtime – this includes language runtimes such as garbage collection, but also operating system integration (which in the case of Rust is provided by the libstd standard library).
The Bee Framework was developed primarily to support the implementation of IOTA Coordicide. As we move towards Coordicide, the IF would like to make this framework as open, verifiable, and usable as possible by supporting the creation of tools, clients, nodes….
The following four milestones have been set by the IF:
Fundamental crates: specification and implementation of the fundamental Crates Bee-trinary, Bee-model, and Bee-crypto. These are the essential building blocks for IOTA development.
FFI: Foreign Function Interface to make the Bee Crates available to other languages. The first project to rely on Bee Crates through FFI will be Firefly. We will also investigate to what extent WebAssembly, wasm, could be an intermediate target.
Rust IRI: specification and implementation of node-specific crates Bee-Network, Bee-Tangle, Bee-Api, Bee-Consensus, and Bee-Gossip. To demonstrate the modularity and robustness of the Bee framework, a node for the current mainnet will be implemented. Some of these crates will be reused for the Coordicide node.
Coordicide: specification and implementation of new Coordicide node-specific Crates after delivery of the research specifications.
Hornet is a lightweight node written in Go and co-developed with the community and IOTA Foundation.
Hornet is a completely new implementation of the core client in the Go programming language. The goal is to have a new core client which will contribute massively to the scaling of the network with a significantly increased performance. Hornet will use the architecture and modular concept of GoShimmer and is intended for low-end devices like a Raspberry Pi. Furthermore the coordinator will also run as a plugin on top of Hornet for a few months.
GoShimmer is a prototype node software in progress that allows nodes to reach consensus without the coordinator so that IOTA networks can be decentralized.
By running a GoShimmer node, you can test the latest developments in the next stage of the IOTA protocol. GoShimmer is a prototype node software that the research department is developing to test Coordicide. When all modules are available, GoShimmer nodes will become the Coordicide test network, which is a release candidate for the next IOTA protocol.
The code in GoShimmer is modular, with each module being one of the Coordicide components or a basic node function. This approach allows us to develop each module in parallel and test GoShimmer with one or more different versions.
Implemented Coordicide Modules
The master branch is the stable version of the GoShimmer software, which includes a minimal set of modules that allow you to send zero-value transactions.
The master branch includes the following coordicide modules:
The autopeering module is divided into two submodules:
Peer discovery: responsible for operations such as discovering new peers and checking their online status.
Neighbor selection: Responsible for searching and managing neighbors.
Modules in progress
Mana: The Mana branch contains an initial implementation of the Mana module in the package directory.
Cellular Consensus: This branch contains a first implementation of the Cellular Consensus module in the package directory.
Fast Probabilistic Consensus: The FPC branch contains a first implementation of the Fast Probabilistic Consensus module in the packages directory. We also have a standalone FPC simulator in this repository.
Spam protection: you can find the initial rate control simulation source code in this repository and the Adaptive Proof of Work simulator source code here.
Bee is a production-ready implementation of the Core Client in the Rust programming language. Parts from all previous developments are merged into a unified platform solution.
The goal of Bee is to develop a standardized enterprise-ready modular EEE software architecture.
EEE stands for “Environment Entity Effect“, which is an event-driven software architecture. It provides the entire communication infrastructure between software components.
This software architecture includes a publish / subscribe messaging mechanism that allows asynchronous communication across all software modules without direct dependency on each other, which allows the system to be very modular and loosely coupled.
Decoupling prevents entities such as individual software modules from interacting directly with each other, instead allowing entities to output “effects” (usually strings) at a specific location (environment). Other entities (modules) can subscribe to these environments to receive any “effects” passed to them. This allows the different modules to subscribe to each other. For this the issuing entity does not even need to know of the existence of its subscribers.
This software architecture is very powerful and overall more resilient to partial system failures due to the publish / subscribe model. This model allows high extensibility so that software modules (plug-ins) can be easily added without damaging or modifying the existing code.
At the end of the development Bee will be the reference implementation. It can be used to run other Node software that conforms to the protocol rules.
With the modular event-driven software architecture (EEE), it will be possible to customize Bee to run all types of nodes for different requirements (Full, Light, Custom, etc.) through the extensions of different software modules.
For example, this would allow the new IOTA Streams to be implemented only when needed. It will even be possible for third-party modules to be implemented.
Also the implementation of a bridge extension for cross-language support is much easier than with the old IXI modules (Bridge.ixi). Thus, also with Bee, every developer should be able to write software modules in the desired programming language, which has a positive effect on the overall development.
Bee effectively becomes an “IOTA Node factory”. So it makes sense to use Bee as a starting platform for customized Node software and to adapt it, rather than programming from scratch.
Bee runs on small microdevices, using even fewer system resources than the old Ict. Bee works without fixed minimum requirements for Ram etc. It uses the system resources that are available. Therefore it will be possible to run Bee on a limited device with only 128 MB RAM. In that case it will inevitably not store as many transactions as when Bee is run on a 64 GB RAM server.
IOTA networks consist of interconnected nodes running the same node software. This software allows read / write access to the tangle, validation of transactions, and storage of transactions in their local ledgers.
Incentives to run your own full node:
Instant overview of status (online/offline)
Complete control over access and therefore to the data in the Tangle
Complete control over the storage of your own transaction history; keyword: Snapshot and Permanode
Infrastructure support: the more nodes there are, the more decentralized the network
As of IOTA 2.0, money can be earned by renting out Mana (Mana-as-a-Service)
Only those who operate their own node can always be sure that reserved capacity / bandwidth is available for themselves and, if necessary, their own customers
If the network is busy and still many transactions are to be made in a short time, from IOTA 2.0 onwards it may be necessary to pay for the use of other nodes with Mana in order to get priority over other transactions (see here). However, those who operate their own node and also hold IOTA tokens will always produce enough Mana to be given preference in transactions in the event of congestion.
Overview of current full nodes:
IRI (IOTA 1.0 / out of service)
IOTA Reference Implementation, Java programming language, the first core client, on 11 Dec ’19 Hornet was added as the second core client. IRI is now outdated and was removed with the Crysalis update, see here.
Completely new implementation of the core client in the Go programming language. The goal is to have a new core client which will contribute massively to the scaling of the network with a significantly increased performance. Hornet will use the architecture and modular concept of GoShimmer and is intended for low-end devices like a Raspberry Pi. Furthermore the coordinator will also run as a plugin on top of Hornet for a few months.
Prototype of Shimmer in the Go programming language. Consensus is already achieved with this node-testing software without a coordinator. GoShimmer implements the various modules of Coordicide, such as autopeering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will gradually be merged with Hornet and later implemented in Bee.
Production-ready implementation of the core client without coordinator in the Rust programming language. All previous developments and ideas from IRI, Ict, Hornet and GoShimmer will be merged into a unified platform. Bee will not only be a node software, it will be a kind of platform, which can also be used for clients or applications.
Wasp is a node for smart contracts. The IOTA Smart Contract Protocol (ISCP) is a 2nd-layer protocol built on top of the core protocol and executed by GoShimmer nodes. The development of this protocol will be fully decoupled into a separate node called Wasp. Wasp will connect to GoShimmer nodes to gain access to the Tangle.
The official Permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle’s unlimited data flow and make it queryable. In other words, it enables unlimited storage of the Tangle’s entire history and makes this data easily accessible.
At its core, IOTA is a protocol for permissionless and trustworthy transmission on the Internet of Things (IoT), enabling a frictionless exchange of data and value (IOTA Tokens) between machines and people. Thus, anyone can secure data on the Tangle and make it verifiable by third parties at no cost. In the IoT, with its low-resource micro-devices, the amount of data (transactions) to be stored and passed through the Tangle via nodes is a major problem, because with IOTA nodes having limited storage space, the Tangle can fill the database quickly. To combat this problem, Nodes have a feature called “Local Snapshots” that allows them to delete old transactions and keep their local copy of the Tangle small.
However, for many business use cases, the data in transactions needs to be stored for long periods of time. For example, financial data must be stored for 10 years in some cases, and identity data must be retained for at least the life of the identity (in some cases, your identity must even be retained beyond your lifetime). For example, consider the case of a transaction that includes a Decentralized Identity (DID) document. A user shares this DID with a government to request a driver’s license, but when the government searches for the DID in the Tangle, it may no longer be available and the request could be denied.
To enable these use cases without burdening the nodes, the IOTA Foundation has developed a permanode called Chronicle; with Chronicle, anyone can store all transactions outside the Tangle in a separate distributed database and make them available as long as they are needed.
Chronicle is the official permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle’s unlimited data flow and make it queryable. In other words, it enables unlimited storage of the Tangle’s entire history and makes that data easily accessible.
Chronicle is a framework for building permanode services that receive transactions from an IOTA network and store them in a Scylla cluster. Originally written in Elixir, it has now been fully ported to Rust to support interoperability with other IOTA projects, such as Bee, and to provide a more secure programming environment.
Explanation: Elixir is a general-purpose, functional, concurrent programming language that runs on the Erlang virtual machine. It can be used to create distributed, fault-tolerant, soft real-time, as well as always-on programs. It provides a complex network infrastructure that can be extended by multiplex networks with different functions by building microservices for each layer that can communicate with public and private datasets under different policies.
Chronicle uses Scylla as its default storage solution because it offers the following key features:
Fault tolerance: users can set a replication strategy to determine how data should be replicated to avoid a single point of failure.
Data consistency: Users can set a consistency level to determine whether a read or write operation is successful.
Fast and efficient data retrieval: Scylla uses LSM-based memory with high write throughput.
Lifetime: Users can define the lifetime of their data
Low cost of ownership: licenses (including free and enterprise licenses) and cost of ownership compare favorably with other solutions
Chronicle also provides tools for building permanent solutions on an efficient runtime environment based on tokio. With Chronicle you can:
Store IOTA transactions in real time, using one or more Scylla clusters. Search for all stored transactions using an HTTP API Extend your own application with custom crates and configurations. To do this, Chronicle includes the following crates that you can use as tools to build your own permanode and extend its functionality:
API: API app that allows you to access the database
Broker: ZMQ broker app for subscribing to new and confirmed transactions on an IOTA node
Common: Runtime code that handles app loading and termination
CQL: Code to decode and encode Cassandra Query Language (CQL) commands to interact with a Scylla node
Storage: Storage app for connecting to a Scylla node, storing and searching transactions on the Scylla node.
Dashboard: This component is an application for managing and monitoring components such as adding or removing Scylla nodes without downtime or connecting to new IOTA nodes in Chronicle Broker.
Query as a service
Basic economics dictates that an economic incentive is necessary to provide any amount of resources to store other people’s data. Therefore, the IF has created a way to offer community members or businesses that Tangle data “query as a service”. This makes Chronicle currently unique. With a little additional development, all Node owners could earn money by charging IOTA tokens for access to historical Tangle data. By requesting a quorum of internal and external nodes, the absolute veracity of the data could be guaranteed.
Functionality can be further extended through multiplex networks by building microservices for second layer solutions that can communicate with public and private datasets under different policies.
A mere Permanode that stores all transactions will not work in a few years due to the constantly growing number of transactions. The required storage space would be exorbitantly high and would cost the operator a lot of money. The goal of a Selective Permanode is to store only the data that is relevant for the operator itself. For larger companies, this would be an enormous incentive to participate in the network with their own Selective Permanodes and at the same time store their own relevant transactions, for a self-determined period of time. In August 2019, well-known community member Olaf van Wijk was already awarded financial support from the Ecosystem Development Fund. These funds will support his research on a “Selective Permanode”. For this purpose Olaf also founded the startup “Aion”. Here you can find the latest status report.
Chronicle is an open source project and everyone is encouraged to contribute to get it closer to production readiness: