Development

GitHub metrics

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

Developer activity (from Coinlib.io)

Explaining the Qubic Computation Model

Part 5: Putting it all together through examples:

In the first part of this series the team has looked at a conceptual overview of the Abra specification, which describes how data flow is achieved within the Qubic Computation Model. In the second part they used the Abra specification to start implementing Qupla, a higher level programming language for Qubic. They introduced Qupla’s most basic entities (trit vectors, look-up tables, and constants) and how they map to Abra. The third part explored the way Qupla uses functions and expressions. The fourth part examined Qupla’s basic operations in detail. This fifth part shows how all the components work together by exploring a few examples of Qupla functions.

The team went through the steps to implement an example factorial() function and a generic array() function template that demonstrates how to use state variables. Along the way they explored some previously unmentioned language constructs, like the import statement and the conditional operator, and some other convenient features of the Qupla programming language.

In this part the team introduced the Qubic Supervisor and how it provides the Environment, Entity, Effect event model as defined by the QCM that allows application components to communicate with each other in intricate ways. They then showed how to integrate a Qupla function into the EEE model and next proceeded to implement Conway’s Game of Life as a simple Proof of Concept example application to demonstrate how it all works together.

In the next part of this series the team will explore in what kinds of interesting ways they can expand on this simple Proof of Concept example.

Coordicide, the effort of removing the Coordinator from the IOTA networks, is well under way in its research phase. One step in the journey towards Coordicide is making the inner workings of the current network set-up fully transparent. The team wants to do that with an open-sourced version of the Coordinator running on Mainnet.

The open source Coordinator, called Compass, was originally released a few months back. One of its main functions was that it allowed anyone to set up a private network, run tests, or develop PoCs more easily than before.

Part of the plan was always to have the Coordinator run on all official IOTA networks. Compass has now been running tested on the Spamnet and Devnet for quite some time. Now the time has come for the final step — Mainnet.

The Coordinator is an important part of the IOTA networks, protecting the network from adversarial parties. The team believes that using the open source version will improve all the aspects of the networks, while making the way they work more transparent for everyone.

They replaced the Mainnet Coordinator on April 10, 2019. The process consisted of releasing a new, breaking version of IRI, together with performing a global snapshot.

The underlying logic is the same as with the soon-to-be-replaced Coordinator. The Coordinator issues signed zero value milestones. Transactions referenced by the milestones are considered confirmed by any IRI node. What changes is the hash function the coordinator is using, to Kerl, and the security level of signatures is bumped to level 2.

If you are interested in the Compass source code, make sure you visit the Compass repo. You can also use Compass to set up private networks to experiment with.

Breaking IRI changes

This IRI release will be a breaking version. This means that to continue running a node that is able to stay in sync with the network, node operators need to upgrade to the new IRI version that communicates with the new Coordinator. This will be version 1.7.0, and you can find it, on the release page.

New coordinator address and milestone start index

The version of IRI will have the new address of the Coordinator embedded in the code to ensure that the correct milestones are accepted.

The new Coordinator will start issuing milestones at a higher index number than what has been used up by the current Coordinator. This ensures that there is a distinguishable transition between the coordinators, while ensuring certain continuity for applications relying on the milestone index.

Global snapshot

The global snapshot was performed on the day of the Coordinator replacement, April 10.

Stateful Client Libraries:

The team officially released the beta versions of their new stateful client libraries, which contain what they call an ‘Account module’. The name does not do justice to what is a very substantial update, so they summarizes the changes in the two blog posts.

Part 1:

Client libraries have always been an important part of the puzzle when building applications on top of IOTA. They are designed to make implementing your ideas simpler, in the language of your choice.

The IOTA Foundation has been maintaining Java, JavaScript, and Golang versions of client libraries for quite some time now.

A couple of months back they set out to redesign the client libraries completely and try to abstract away as many complicated operations as possible. So that developers would only have to care about what they really care about: sending transactions and receiving transactions. All without the complicated bits and pieces that require an in-depth knowledge of the IOTA protocol.

What do the new libraries do?

Previously when working with IOTA client libraries, developers had to implement many components themselves from scratch. This required an advanced knowledge of many IOTA concepts. For example, you had to be quite intimate with:

Transactions

Bundles and how to construct them

Knowing which addresses are safe to use for a deposit and which can be used for input selection

Promotion and re-attachment of pending transactions

and much more

As the client libraries had no state, the developer had to manage or fully rely on the network. Even operations like getting transaction data required a network call, and the pruning of old ledger data by snapshots had to be taken into account.

All this made building on top of IOTA unnecessarily complicated. The upfront investment you had to make before being able to send a transaction was a real issue.

Especially when you wanted to experiment with simple applications on top of IOTA. With the new libraries however, most of the low-level aspects are abstracted away. A developer can create an account and start sending and receiving transactions with much less effort.

The new client libraries store the account information locally, removing the need to call nodes for information like address state or balances. They are also resilient to snapshots. The libraries now:

Store the account information and settings locally. You can also export and import existing accounts.

Store pending transactions locally.

Handle the promotion and reattachment of pending transactions via a predefined strategy. You can also define your own strategy. The reattachment and promotion functionality is supported via a plug-in and you can develop your own plug-ins that extend the library functionality.

Have a notion of which addresses from your account have been deposited to and spent from, and which should be used for input selection. So whenever you request a deposit, you are doing so in a safe manner.

Provide event handling functionality. You can now listen out for different events, for example every new deposit, or every confirmed, outgoing transaction.

Introduce a concept of Conditional Deposit Addresses (CDAs), which are now the primary means of communicating with depositors.

Part 2:

In this post, the team looks closer at the concept of Conditional Deposit Addresses (CDAs).

CDAs are special addresses that allow you to specify the conditions for which they stay usable. As long as the conditions you specify hold, the CDAs can be used for withdrawals and deposits.

The main use for CDAs is to avoid address reuse. When you request IOTAs from a party, you create a CDA that is active for a certain period of time and that can specify the exact amount of IOTAs. This way, you communicate intent to the sender, who then makes a judgement on whether to make a deposit. A simplified flow is:

You generate a CDA. When creating the CDA, you specify conditions like the timeout — for how long the CDA stays valid and can be deposited to. Or an amount — how many IOTAs you expect the sender to deposit to the address. You share the CDA with the depositor via a medium of your choice and serialized as an object of your choice, for example as a QR code, protocol buffer, or a magnet link. The depositor either sends tokens to the address specified in the CDA, or requests a new CDA if for example the CDA has already expired.

CDAs are simple, descriptive objects and you can serialize them into any format. The libraries can parse the magnet link.

Try out Conditional deposit addresses

To showcase this concept, Luca Moser has built a web application that works as a web wallet (note — this runs on devnet using test tokens).

Go to the Sigma Wallet website Create an account. Generate an address in the web wallet with amount set to 1000. Click the “COPY RAW ADDRESS” button and use it to get funds from the the Devnet faucet. The funds should be available shortly, as you can see in the Balance section. Generate a new address in the web wallet and click “COPY MAGNET LINK”. You can paste this magnet link into the address field of the “Send” section of the wallet and send a specific amounts to yourself.

If you specified the amount of IOTAs when generating the CDA, the IOTAs will become available in your balance as soon as they arrive. Otherwise they will be blocked until the CDA expires, which is 30 minutes in this case.

Donation addresses and other scenarios

One of the scenarios that is enabled by CDAs is the implementation of fixed-time donation addresses. You display a CDA on your website, for example as a QR code. And, every time the current CDA is about to expire, let’s say in the last 48 hours of the validity of the CDA, you generate a new one and display a new QR code. Leaving enough space for the already incoming transactions to safely come in and making sure all new donations are picked up by the new CDA.

You can see an example of this approach implemented in Go in this donation PoC repository.

You can read more about the client libraries in IOTA documentation. Or get the libraries from their respective repositories:

CClient is an IOTA client library implemented in C. This is one of the modules in the entangled project. This post outlines how to run CClient in the ESP32 development framework.

Building the IOTA CClient project on ESP32

If you are new to ESP32, please follow this document to build and run a hello_world example. Below we describe the CClient build.

Requirements:

Step 1: Checkout and initialize the project

Step 2: WiFi AP Configuration

Setup 3: Build and flash image

What’s next?

CClient is still an early development stage, but the core and extended APIs are ready to use, so you can:

Test CClient APIs on ESP32

Porting CClient to other IoT devices

Report bugs on the entangled repo

The IOTA Foundation would like to establish a community committee that will help them with assessing the development and release for significant product changes in the IRI.