Development

GitHub metrics

Development is ongoing. Commits on public GitHub appears regularly, several times a day.

Developer activity (from Coinlib.io)

The team has released version 0.6.0 of Ict.

The major features are:

+ implement EEE (Environment Entity Effect) infrastructure to enable inter-ixi communication

+ translate gossip listeners and gossip preprocessors to EEE to simplify IXI

+ let modules offer their functionality through API (/getModuleResponse)

+ allow module developers to add modules to Ict from loaded classes instead of having to load from a separate .jar file -> simplifies module development and testing

+ increase efficiency by checking incoming bytes against known transactions to avoid decoding the same transaction multiple times (#51)

+ hash gui_password before storing it in ict.cfg (#59)

+ fix #53 (adding the same neighbor multiple times to ict.cfg)

+ 5s timeout after submitting wrong password to GUI to prevent brute-force attacks

Ict 0.6 introduces EEE (Environment Entity Effect), a new concept that does two things at once:

Minimizing IXI technically by replacing various specific infrastructures (addGossipListener, addGossipPreprocessor) with a single general solution (addListener)

Extending IXI functionally by introducing Inter-IXI Communication

EEE streamlines all kinds of event-based architectures on top of IXI. Entities such as IXI modules can subscribe to Environments and will be notified about all Effects published to those environments by other entities. This enables IXI modules to subscribe to each other and effectively work together.

Not only does 0.6 introduce a way for modules to make their functionality available to other modules via EEE but also through the Ict API. The API route “/getModuleResponse” allows to send API requests to any installed module directly. Modules will no longer have to run their own API. This will increase the user experience significantly since users won‘t have to open separate ports for IXI modules (CHAT.ixi will utilize this new feature soon).

Yet 0.6 hasn’t forgotten about the developer side of IXI and enables “virtual module loading”, a way for module owners to test their modules during runtime, without having to compile their module into a .jar first.

Besides these convenience features, the efficiency of Ict 0.6 was further increased by checking the encoded bytes of incoming transactions against those of already known transactions. This prevents Ict from unnecessarily decoding the same transaction into trytes over and over again, when received from multiple neighbors.

Security has also been improved. Passwords in Ict 0.6 will now be hashed, and no longer stored as plain text in ict.cfg. Additionally a short timeout has been introduced when connecting to the API with an incorrect password, to prevent brute-forcing passwords.

Bridge.ixi

Until recently, modules for the Iota Controlled agenT (Ict) had to be written in the same language as its core. However, the vision of the IOTA eXtension Interface (IXI) is to enable cross-language support; everyone should be able to write modules in their desired programming language. This is exactly what Bridge.ixi has solved. By giving everyone the opportunity to participate with their desired programming language, Bridge.ixi will have positive impact on the overall development.

How does Bridge.ixi work?

Bridge.ixi provides a socket mechanism to allow external modules interact with IXI. By participating in the Environment-Entity-Effect (EEE) infrastructure, interaction between modules is possible. Regardless of whether it is a bridge module or not, all modules can participate in the same way. By acting like a proxy, Bridge.ixi will forward external requests and return internal responses. As a high-speed I/O engine it handles requests asynchronous.

Bridge.ixi makes use of protocol buffers, an efficient, language-neutral mechanism for serializing structured data. With protobuf3, the following languages are supported: Java, Python, Objective-C, C++, Dart, Go, Ruby, C# and JavaScript. Third-party implementations are also available for C, Rust, Elixir, Haskell, Swift and many more.

Get started

It’s pretty simple. After you have installed Bridge.ixi for your Ict, all you need to do is establish a tcp socket connection to the Bridge.ixi server running on port 7331. Once you have done this, you are able to send/receive protocol buffer messages. To get a better feeling for the protocol buffers, it is a good idea to take a look at the official protocol buffer guide and the available module example. If you need further assistance, we are happy to help you in the #ict-help section of Discord.

Repositories:

https://github.com/iotaledger/ict/releases/tag/0.6

https://github.com/iotaledger/bridge.ixi

Explaining the Qubic Computation Model

Abra specifies an extremely minimal general instruction set that is designed to provide natural mapping of dataflow based functional programs to the wildly varying types of hardware run by IoT devices. That means it can be easily mapped to run on any device from CPUs, to GPUs, to FPGAs, to ASICs. However, Abra is primarily geared towards creating FPGA and ASIC circuitry. It is expected that in the future a large part of all IoT devices will be running on such hardware, and general-purpose CPU/GPU devices will mostly be used for PoC solutions and/or server solutions that target humans.

Abra is unique in that it employs trinary logic and directly supports wave-pipelining. These are two aspects that allow it to maximize the efficiency of the associated code, which is important for IoT devices due to their limited energy and processing resources. Wave-pipelining of combinatorial circuits has been shown to achieve clock rates of 2 to 7 times those possible for the same circuits with conventional pipelining. Additionally, using trinary-based circuits can result in up to 50% more energy-efficiency due to the denser representation of values. Note that such circuits can even be created with traditional binary NAND gates.

In this article the team discusses the basic concepts used in Abra:

Binary versus trinary code and data

Transformation through look-up tables

The Abra code unit layout

Anatomy of a branch

Anatomy of a branch

Abra’s merge instruction

Reactive dataflow in Abra

Abra pseudo-code

The Abra specification defines dataflow while staying largely agnostic of implementation by using a very limited set of building block instructions. Abra supports a cooperative multitasking mechanism. This mechanism works in conjunction with the Qubic Supervisor which the team discusses in Part 2. They described a pseudo-code notation for Abra instructions that will help the team get a feel for the Abra specification itself so that all parts will come together nicely. In the 2 part of this series the team delves deeper in the Qupla programming language, which implements the Abra specification.

In this part, the team uses the Abra specification to start implementing Qupla, a higher level programming language for Qubic.

Qupla is an acronym that stands for Qubic programming language. The goals the team is trying to achieve with Qupla are twofold:

Provide a trinary data flow programming language according to the Abra specification that can function as a higher level programming language for Qubic. Lower the barrier for programmers to get started with Qubic programming by leveraging existing knowledge as much as possible. This means that we try to keep the language and its behavior as familiar as possible while still providing access to the new and unfamiliar functionality of the Qubic Computation Model.

At first glance, Qupla has a number of things in common with existing programming languages. Some concepts, entities and constructs will look very familiar to programmers, but there are also a few twists that will be completely new. The most obvious new twist, of course, is that Qupla is a trinary programming language.

The basic data type in Qupla is the trit vector. The team can create user-defined types for specific fixed-sized trit vectors and use constant values that will automatically convert to trit vectors. Another basic entity in Qupla is the look-up table, which is key to the inner working of many of Qupla’s concepts. In the 3 part of this series the team delves deeper into how these basic entities are used with Qupla programming language constructs.

Part 3: Qupla functions and expressions:

This part introduces how the team can use functions and expressions to create Qupla programs.

The article includes:

Qupla functions

Expressions

Function declarations

Function type specifiers

Templates

Automatic template instantiation

Function body

Function state variables

Qupla functions are made up of one or more expressions. Functions can be analyzed as pure function even when they have state associated with them. Similar functions that operate on different types can be distinguished by using a type specifier, and templates remove the need for cloning functions for each of those different types.

This part shows what basic operations Qupla provides.

Qupla functions are made up of one or more expressions. There are 5 basic operations in Qupla: function call, vector concatenation, vector slicing, LUT look-up, and merge execution branches. The first 3 reduce to wiring-only on FPGA, while the other 2 are simply implemented as multiplexers. Functions are instantiated as they are called. On CPU there are reasonably efficient implementations for the 5 operations and the function instantiation can be mimicked. The team has also seen that decision logic can be implemented using a combination of LUT look-up and merge operations.

In the next part of this series the team will put all the parts together in a few examples and discuss them in detail. They will also introduce a few more language features.

March was an extremely busy month. The team managed to get yet another community member on board to help out the Omega team: say hi to ben75, our Qupla IntelliJ plug-in creator. Benoit will be working on IXI modules at first, while keeping the IntelliJ plug-in up-to-date as well.

Ict

The latest version is now the 0.6 release. Lukas introduced a first version of Economic Clustering (EC) in Ict to be able to test out some of the ideas around EC, and also added the Environment-Entity-Effect (EEE) message passing model that was spearheaded by the Qubic team, which is central to Abra and the Qubic Computation Model. As usual the community was enthusiastically involved and helped iron out bugs and discussed interesting ideas.

IXI

Benoit jumped right into the IXI world by getting acquainted with Ict/IXI and started working on the serialization.IXI, which will provide a simple way to store/exchange structured data on the tangle. Lukas started working on the report.IXI, that can report node information to external services. Samuel finalized the graph.IXI and the timestamping.IXI with some documentation, updated the PoC chat.IXI together with Lukas to allow it to work correctly with the latest version of Ict, and he is now working on the bridge.IXI, which allows modules written in any programming language to interact with Ict.

FPGA

Donald has been deep into exams but still managed to find time to discuss some of the areas of the FPGA implementation that still need a good solution. But it looks like he will get some relief in the near future, because we found someone that has the right qualifications to help out with FPGA development. More about that next month, hopefully.

Qupla

March was mostly spent creating a series of articles that explore the Qubic Computation Model (QCM). The team already released one article specifically about the Abra specification, and three more articles about that introduce the Qupla language, with even more articles to follow soon. While writing about Qupla and the QCM, they took the time to straighten out a few syntactical constructs to be more consistent, plus they finally added binary, trinary, and hex constant literals to the language.

The team also took the time to define a simple pseudo-code for Abra that allowed them to explain how certain Qupla language constructs are implemented in Abra. The latest version of the interpreter also includes an interesting new community contribution:

The community member lunfardo created a converter plug-in for the Qupla interpreter that can translate Qupla into YAML. He then proceeded to create his own version of a Qupla interpreter, complete with a Supervisor module in Go. It can take the YAML file and execute the code flawlessly. Check it out here. It will be interesting to see what execution speeds he can achieve.

Videos from Official IOTA Foundation Youtube channel:

IOTA Smart Cities Webinar #2 — Technical Deep Dive:

In this webinar, IOTA’s Director of Ecosystem, Lewis Freiberg, explores the themes and possible submissions for them. Additionally he walks through a code example that integrates IOTA onto a Raspberry Pi 3+.