run/kiri/run: Increasing the speed of Kiri

I keep improving Kiri to measure the efficiency of MAIA. Today I bring you a new short post with its latest enhancements and improvements. While in the previous post I focused on its autonomy, in this I will focus on its speed.

I am of the opinion that each project must have its identity. Therefore, before telling you about its improvements, I present you its logo:

It is not very good, but at least it is quite descriptive (IRI in a box) 🙂

When we talk about improving the speed of an application we can think of several things such as remove a bottleneck, parallelize the execution, reduce order of complexity or use a new library among others things. I am sorry to disappoint those who expect an ingenious solution … .

To put you in context, Kiri is an application that allows you to running a private IOTA testnet in a Low Cost Single Board Computer (LCSBC), something that can be very useful to carry out certain types of tests.

What is not necessary to running a private IOTA testnet in a LCSBC? Neither run the IXI hub nor load the addresses of previous epochs.

To what extent does the above affect the speed of Kiri? Well, I think an image here is worth more than a thousand words.

I must admit that the graphs do not indicate anything about the overall speed, but the reason is simple, it is complicated to measure accurately and it is logical to conclude that (usually), if you use less computational resources the overall speed will be higher. I think it is unnecessary to develop a convoluted metric to prove it, it is only necessary to use the new version of Kiri to realize that it works faster than the previous one (at least 25%).

Any other improvement? Some other more, although most of them are focused on fixing errors and improving the integration of IRI in Kura.

That’s all. In a few days I will bring you news from MAIA.

In case you want to donate some IOTAs to support my work, send them to my personal IOTA address:

KIFEHFFMQDPHLHGURUXDZGTJVDZMDLCFSVXXRNXKCIXJZSJNBWULBLQXYSNZNVGIJXVCITXREHUUKCHGDCSEBGYDEB (it is no longer my address, use my MAIA)

Or better yet, send them to my MAIA (we are making changes to the protocol and sometimes the node that we use is down, so for now it is better that we do not take risks :’) ): donation address.

Increasing the autonomy of Kiri

In the previous post, I introduced MAIA, a MAM-based protocol that allows generating something similar to a fixed IOTA address.

Today, I present a handful of improvements in Kiri, which have been made to measure the efficiency of MAIA.

If you do not know what is Kiri, I just tell you that it is an application for Kura that allows you to deploy private IOTA testnets in LCSBC (it has been successfully tested in Raspberry Pi 2B/3B and Up Squared).

You can get more information about Kiri on its presentation post and download it from its repository (it includes ready-to-use packages).

The main improvements, from least to most important, are:

Added patch to use unsigned snapshots

The configuration of gitignore excluded a patch that allows using unsigned snapshots in IRI . I am so sorry for anyone who had tried to deploy Kiri compiling it from the source code …

Integrated iota.lib.java – JOTA

Jota has been patched, so it can work on Kura and it has been integrated into Kiri. Now, it is possible to use code that is using IOTA’s API to work with our private IOTA testnet.

Self-coordinated node

A coordinator has been integrated into Kiri, so it is no longer necessary to use https://github.com/schierlm/private-iota-testnet for this. A Kiri private IOTA testnet is now autonomous.

The configuration of Kiri allows you to establish the interval for issuing new milestones by using the coordinator.

That’s all folks (more coming soon 😉 ).

In case you want to donate some IOTAs to support my work, send them to my personal IOTA address:

KIFEHFFMQDPHLHGURUXDZGTJVDZMDLCFSVXXRNXKCIXJZSJNBWULBLQXYSNZNVGIJXVCITXREHUUKCHGDCSEBGYDEB (it is no longer my address, use my MAIA)

Or better yet, send them to my MAIA (we are making changes to the protocol and sometimes the node that we use is down, so for now it is better that we do not take risks :’) ): donation address.

Kiri: Private IOTA testnet in Kura

Before explaining what is Kiri, let me ask you some questions:

1. Do you want to do some tests using IOTA nodes?
2. Do you want a private IOTA testnet to have full control over the transactions?
3. Do you have low-performance devices like Low-Cost Single Board Computers?

If your answer is yes to more than one of these questions, Kiri may be of interest to you. Maybe you have a device with enough resources to run a full node, then you can use IRI. Perhaps you only need to carry out some tests, in this case, you can create a private IOTA testnet or use the PoWbox.

What is Kiri for? To create private IOTA testnets easily using LCSBCs (I think that a Raspberry PI 2 B is enough). Anyone who has deployed an IOTA node will know that the minimum requirements are higher than what you can have with a PI. If you have also tried to install it on an ARM device you will also know that deploying RocksDB is not a simple task.

If you only want to do some tests using IOTA and you want to have full control over the transactions, Kiri can be your ally. All you need is a device running Kura. As you use a private IOTA testnet, few computational resources are needed and a PI could be powerful enough for it.

You can download the code here. In the demo directory, there are deployable packages ready to be used (tested in PI2B, PI3B and Up Squared). The code is 80% third-party resources and 20% code to execute them in Kura.

You must consider that it is an experimental tool. On the negative side, surely its use denote several failures, but on the positive side, in the future, it will allow doing many more things ;). If you have a bug or an idea, create an issue in GitHub.

I hope you like Kiri. In case you want to donate some IOTAs to support my work, send them to my donation address.

Parallelizing IOTA transactions in Kura

This post is shorter than the others, but no less interesting :). We could even say that for us it may be the most important one so far.

What’s the fuss about? From now on, Jura is scalable in terms of locations stored in the tangle. How? Using IOTA’s workers.

For us, our proposal is nothing more than a proof of concept. Aspects such as health or privacy should not be treated lightly and we are not experts in any of those areas. Therefore, we focus on checking whether what we want to do is possible to validate our idea.

Something critical is the storage of locations in the tangle, because although it is ‘free’, it is not as fast as we need it. In our last post, we published experiments on how we try to make IOTA transactions more quickly. We are proud of having implemented this funcionality in Jura.

From now on, Jura has a new feature, iot.challenge.jura.worker.iota.feature. With this, we can create a cluster of IOTA’s workers that are coordinated using MQTT. We want to highlight that it is not the same to send as many transactions as possible to the tangle with random data than with data which follow a given pattern that must be maintained. Our approach, almost identical to the one used in the collaborative approach, is as follows:

• Each cluster’s node uses the worker.iota service.
• The service adds itself to the list of IOTA’s workers of the cluster, publishing a message in topic /jura/cluster/iota/worker/<worker-id>.
• The IotaService assigns jobs to each worker by publishing them in the topic /jura/cluster/iota/todo/<worker-id>.
• The workers publish the results of the jobs in the topic /jura/cluster/iota/done/<work-id>.

At this stage, the question is whether is it necessary to store 10, 100 or 1000 locations per minute? Now we can. For example, as a result of two simulations using the FIRMA address, we have obtained:

• Using an Up Squared: 11 transactions. 40.9 seconds each transaction.
• Using our LCSBC’s cluster: 35 transactions. 12.86 seconds each transaction.

Obviously, the next question would be, how many computers are necessary to make X transactions? We do not know, but now it is possible to check it 😉

The Race to the Tangle II. Teamwork

This post is a continuation of the race to the tangle in which we discuss how we try to increase the number of transactions we make to the tangle with the hardware we have.

For those who are not sure about what we are doing, we would like to remark that we are developing an IPS and storing locations in the IOTA. So we are not developing an IPS on the IOTA.

Why do we store locations in the tangle? Because our goal is to use the locations as evidence of facts, and we believe that having them stored and signed in the tangle is ideal for our purpose. You can review the last part of this post to see an example of what we do with the locations which are stored in the tangle (notice that the images of the web are gifs).

For us, the locations that we store in the tangle are like a snapshot of the current state of the installation. Obviously, the more locations we store, the more representative the snapshot will be. Therefore, the underlying issue to be addressed is to increase the number of locations stored in the tangle with the hardware we have. We do not talk about using cloud solutions or better hardware, but to optimize the performance of the hardware that we are using.

After these considerations, it is time to move on to the interesting part.

First of all, the code. Keep in mind that it is a code to carry out tests (not for production). Before using it, you should analyse it in order to understand how it works.

We have the following Low-Cost Single Board Computers (LCSBC):

• 1 x Up Squared.
• 1 x Raspberry Pi 2 Model B + Micro SD 32 Class 10.
• 3 x Raspberry Pi 3 Model B + Micro SD 8 Class 4.

We use Eclipse Kura in all the LCSBC so they can easily communicate with each other by MQTT. Using the MQTT connection we can create a cluster of LCSBCs (hereinafter nodes). Our approach is as follows:

• Each node uses the worker service.
• The service adds itself to the list of workers of the cluster, publishing a message in topic /mide/iota/workers/<worker-id>.
• The node which starts an execution uses the manager service. Speaking properly, the execution uses the service (there is no public manager service).
• The POW is not parallelized, but the transactions. Why? Because: i) it is a complex task, and ii) without a fast connection between nodes it does not make sense (this would even slow down the system).
• The manager assigns jobs to each worker by publishing them in the topic /mide/iota/todo/<worker-id>.
• The workers publish the results of the jobs in the topic /mide/iota/done/<work-id>.

Analysing our previous results we realised that the deviation in the average transaction time per LCSBC is high. Therefore, we follow two approaches:

• Collaborative: Each transaction is assigned to a free worker. It should be most efficient.
• Competitive: The workers compete with each other to be the fastest in each transaction (like blockchain mining). It should be more stable.

We have conducted two experiments in which we have sent 300 transactions to the following addresses:

• https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999COMPETITIVEAPPROACH
• https://thetangle.org/address/999999999999999999999999999999999999999999999999999999999999COLLABORATIVEAPPROACH

Unfortunately, there is a bug in the IOTA library which provokes that sometimes an exception occurs in the POW. In our implementation, we discard these transactions, and therefore we do not consider them in the results. It is important to note that the error occurs during the POW, so the results would be better without this bug.

The bug also affects the execution in a different way depending on the configured mode. While in the competitive mode the nodes work until the end of the execution because these nodes are called for each particular work, in the collaborative mode this does not happen. Our solution to analyse the results has been keeping only the valid data of the competitive mode and all the data until the first bug in the collaborative mode. In the collaborative mode we have done several tests until we achieved a case in the bug appear late (after many transactions).

The results are:

Competitive

• Transactions: 232.
• Time: 4708 seconds.
• Time per transaction: 20.29 seconds.
• Transactions per hour: 177.4
• Variance: 237.51
• Standard deviation: 15.41
• Maximum transaction time: 86 seconds.

Collaborative

• Transactions: 203.
• Time: 3107 seconds.
• Time per transaction: 15.6 seconds.
• Transactions per hour: 230.75.
• Variance: 9984.75.
• Standard deviation: 99.92.
• Maximum transaction time: 679 seconds.

Here you can find the comparison with the previous ones:

The Race to the Tangle

These days we are using the starter kit that we got for our proposal for the Eclipse Open IoT Challenge 4.0 to carry out different tests. With the kit we got three Raspberry Pi 3 and one Up Squared* Grove* IoT Development Kit. All this costs about 400$, a great reward.

In our proposal, we use IOTA to store information, being the search for the nonce for the proof of work in each IOTA’s transaction the most computationally expensive part. You can send everything you want to the Tangle without spending IOTAs, but unless you have free electricity, the transaction will not be free. However, what worries us is not the marginal cost of electric power, but the ratio of transactions we can achieve using low-cost single board computers.

We have decided to carry out some experiments and we share the results with you. We have proceeded as follows.

We have the following hardware:

• Raspberry Pi 2 Model B.
• Raspberry Pi 3 Model B.
• UP Squared.
• 1 Micro SD Class 10 32GB.
• 1 Micro SD Class 10 16GB.
• 1 Micro SD Class 4 8GB.

Using this hardware we have prepared four configurations:

1. UP Squared.
2. Raspberry Pi 3 Model B + Micro SD Class 10 16 GB.
3. Raspberry Pi 3 Model B + Micro SD Class 4 8GB.
4. Raspberry Pi 2 Model B + Micro SD Class 10 32 GB.

For all configurations we have installed the latest version of Kura (‘Raspbian (Model 2 or 3, No Net)’ for UP Squared).

Using Jura code we have developed a Kura’s package to test the efficiency of a device making transactions to the IOTA’s tangle. You can download the code here. If you want to try it, we warn you that (in our case) the latest version of Kura’s web does not show the service’s configuration menu the first time we deploy it. The solution is simple, install, uninstall and reinstall…

We have sent in each experiment 50 transactions to the following addresses:

1. https://thetangle.org/address/999999999999999999999999999999999999999999999999999999999999999999999999UPSQUARED
2. https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999999999PITHREEGOODSD
3. https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999999999999999PITHREE
4. https://thetangle.org/address/9999999999999999999999999999999999999999999999999999999999999999999999999999PITWO

And the results are:

1. UP Squared: 31.17 seconds each transaction (115.51 per hour)
2. Pi 3 Model B + SD Class 10: 103.25 seconds each transaction (34.87 per hour)
3. Pi 2 Model B + SD Class 10: 154.4 seconds each transaction (23.32 per hour)
4. Pi 3 Model B + SD Class 4: 196.52 seconds each transaction (18.32 per hour)

Obviously, the result after 50 transactions using a Kura’s package should never be used as a measure of the efficiency of the device, but it allows us to intuit the approximate performance of each one.

Our Approach. Part II. Trusted IPS

We have been waiting to post this for weeks. It is not because we are playing hard to get, we just wanted to see how far we could go 🙂

Let’s contextualize. When we conceive our proposal we made the following reasoning:

1. In several situations, the reading of a sensor can be enough evidence to prove something. Thinking about location examples, the above could be useful if:
   • A person wants to prove that he/she was in a certain place at a given time.
   • A delivery person must bring a package to an address.
   • A worker who must be in an area for a period of time.
   • …
2. If someone wants to use a reading as evidence of a fact, he/she should be the one detected. The reason is very simple, false readings can be generated:
   • A child who plays truant from school.
   • A delivery person who sets a fake GPS location.
   • A worker who wants to pretend that he/she works more than he/she actually did.
3. For the same reason, detections should not be used as accusatory evidence:
   • A person can simulate that another person was in a restricted area.
   • A person can simulate that another person was in a place to deny that he/she could be elsewhere.
   • A person could use a stolen device to commit any felony.
   • A person could use a modified device to impersonate another person.
4. In addition, the absence of detections should not be used as accusatory evidence either, since the readings could be deliberately omitted.
   • A person does not want to register the delivery person who goes to his/her home.
   • A company does not register an action of its clients to cancel any of their rights.
5. To be able to use a reading as an evidence to a thrid party, it should be recorded in a way that ensures that:
   • The authentication of the sender of the message can be checked.
   • The message is registered when it occurs.
   • The message can not be modified.
   • The message can not be repudiated.

Before explaining our approach we would like to make a small point. Our starting point was: let’s use IoT as evidence to prove facts. We believe that extreme generalizations are extremely bad, and we are convinced that the reader can come up with several solutions to the above problems. We did not want to propose anything that seemed like a good idea but in practice would not work at all. Why our proposal is a Trusted IPS for Nursing Homes? Because we believe it is useful and we can deal with the above problems in this area.

Our proposal

We believe that the best scenarios to deploy a proposal are those in which the following requirements are maximized:

1. The detected one obtains benefits:
   • Direct: He/she can prove a fact.
   • Indirect: The processing of data provides some benefits (emergency attention, customized care, …).
2. The detector obtains benefits:
   • Direct: Location of workers, logistics optimization, sale of data, …
   • Indirect: Transparency policies, analytics, …
3. The detected one should not be interested in cheating the system.
4. The detector should not be interested in cheating the system.

How do these requirements fit with a nursing home?

Detected benefits

Residents and their relatives can obtain great benefits:

• Guarantee of adequate attention.
• Help in emergency situations.
• Behavioral study for the early detection of diseases (degree of mobility, level of physical exercise, sociability, dementia, Alzheimer, …).

Detector benefits

The owners and staff of the nursing home can also obtain great benefits:

• If one of your loved ones must be admitted to a nursing home and you must choose one. How would you rate one that offers you a guarantee of the care of its residents and that gives you mechanism to enforce your rights?
• Location of residents.
• Location of staff.
• Processes automation.

Interest in cheating by the detected

This requirement is the most complex to maximize because necessity is the mother of invention, and we know that some people may try to cheat the system to obtain other benefits (better care, financial compensation, etc).

However, we must understand that the value of the data is proportional to the security policies implemented. The reading of an isolated detection sensor should not have the same value as that of a set of them following a sequence, plus a NFC reading, plus … . To clarify, we do not encourage to use 20 different types of sensors, we encourage to establish the necessary mechanisms to avoid fraudulent use of the system.

We know that our proposal suffers from not addressing this point with the necessary depth. This is due to two reasons: i) only the analysis of the necessary security policies could take months and ii) without analyzing the day-to-day in a nursing home we are not qualified to do so. For our proposal we ‘only’ use BLE Beacons for the reasons mentioned here.

On the other hand, we would like to highlight that we think it would be relatively easy to convince residents to carry a beacon with them because many of them already carry a device of similar size to call emergency services (or why not, improve the current devices).

Interest in cheating by the detector

Here the question to be asked should be: What is better for the nursing home? That it can modify the data or that it can guarantee that it can not modify the data? For us there is no doubt that the second is much more beneficial both from the ethical and from the economic point of view. And how can they give this guarantee? We can think of two ways to do it:

1. Using an intermediary. An outside company hired by the nursing home (could be you 🙂 ) would be responsible for recording the readings and ensure they are real.
2. Storing the data in a blockchain.

Trusted IoT

This part has given us more headaches than any other since the technology used is more complex and abstract. When the challenge began, our knowledge of the blockchain was basic. After a few months experimenting with this technology we feel that we still know very little, but at least we have unlearned some misconceptions.  Our vision of the blockchain is that:

1. Forget the money! The most outstanding feature of the blockchain is that it allows us to decentralize trust. Obviously this is ideal for monetary operations so we believe that the association Blockchain=Money will prevail for a long time.
2. Integrity and non-repudiation is guaranteed by design.
3. IoT and blockchain combine perfectly.
4. There is a lot of misinformation. Many people still underestimate the blockchain and many others overestimate what can be done in its current phase.
5. The smart contracts will be the trigger for the use of the blockchain in all areas, but we believe that not in the current conception of the smart contracts.

When you start to study the blockchain, the first thing you should do is not to think about it as a whole, since there are multiple proposals that experiment with multiple concepts. There are public, private and hybrid blockchains, with support for smart contract or not, for general use or for niches, based on mining, preminated, … .

In our case, after analyzing several blockchains we decided to use IOTA since it allows us to i) store data, ii) with no fees iii) quickly. We are not going to talk much about the IOTA since the only thing we would do would be to paraphrase its website. But we would like to encourage you to investigate about it since for us, it is the blockchain with better future prospects.

We only use IOTA to store locations, in which we will delve into our next post. To understand how we do it, we must understand that:

1. We talk about IOTA as blockchain, but IOTA is blockless and it is based on tangle.
2. A transaction validates two previous transactions. Thanks to this, the miners have no place. Neither the fees. It is possible to make transactions with zero value.
3. If a transaction has no value, it is not necessary to prove that we own the private key corresponding to the address that generates the transaction.
4. If it is not necessary to prove that you own the private key, you can use the field for the signature of the message to store any other data, in our case messages with the location that we have previously signed with PGP and, if necessary, encrypted with AES.

The way in which we use the IOTA to store locations allows us to guarantee that:

1. The locations are stored in a distributed ledger and it is not possible to block their access.
2. A message can not be repudiated.
3. It is not possible to modify or remove registered locations.
4. It is not possible to add past information that can be trusted. The timestamp of the location and the timestamp of the IOTA’s transaction will determine if the message should be trusted or not.

As we have anticipated, in the next post we will present the last feature of Jura and we will explain exactly how we do the above.

We would like to finish this post highlighting that in our proposal we only use a minimum part of what IOTA offers. Once we have the data in the tangle, i) why not sell them?, ii) why not offer a better service on demand?, iii) why not use them to build an oracle for a smart contract?, iv) thinking about IOTA snapshots, why not deploy a permanode that allows access to the data under a freemium model?

In the top 12 proposals!!!

We are glad to announce that we were selected among the top 12 proposals. (https://medium.com/@roxanne.iot/open-iot-challenge-4-0-scholars-cf750ec3b14b)

Last week we received the kits and now we are carrying out our first tests.

Be alert!!! New post with the preliminary results very soon.

 

 

 

 

Our Approach. Part I. Indoor Positioning System

For the Open IoT Challenge 4.0 we propose a “trusted indoor positioning system for nursing homes” but, first of all, it is necessary to ask ourselves, do we know what is this?. In these first entries, we will try to explain it in a simple way.

The basis of our proposal is an Indoor Positioning System, IPS, which is a system capable of positioning people or objects inside buildings. Let’s assume a building plan like the following.

An IPS would allow us to know remotely the location of people or objects in this building. From now on we will refer generically to the location of elements, understanding that an element could be anything either people or objects.

For our IPS Proof of Concept, PoC, we will use some wireless technology such as wireless networks or Bluetooth. We have opted to use Bluetooth Low Energy beacons, BLE beacons, hereafter beacons.

These beacons allow us to calculate the distance by measuring the attenuation of the signal power. The simplicity of these devices, their low cost, low weight and low energy consumption makes them the perfect candidates for the PoC of our IPS.

Usually, the IPSs based on beacons use fixed advertisers and mobile scanners (commonly smartphones). This occurs thanks to i) systems that can work for years using small batteries, ii) the small number of Bluetooth signals in the particular environment or iii) greater anonymity of the users.

Reverse IPS based on beacons, with fixed scanners and mobile advertisers, are less common since they imply several limitations such as i) the Bluetooth signals interfere with each other so the number of elements to be positioned is limited, ii) the IPS calculates the position of the elements, so it scales worse, iii) lower anonymity of the users, iv) higher energy consumption of the system, among others.

However, if the above limitations are not a problem for a specific solution to be deployed, two interesting properties should be considered:

1. Carrying a device of reduced size, weight and long-life battery, an element can be positioned for years.
2. The IPS captures the signals, so it can trust them. This property is one of the bases of our proposal. We will write about it in the next entry. For now, it is enough to say that in our approach we will develop a kind of IPS which has this property.

In order to deploy our IPS, we will need to install scanners in the buildings. These scanners can be any kind of programmable devices with BLE and network connectivity. We believe that Low Cost Single-Board Computers, LCSBC, are the best option. The location and number of scanners to be used in each building should be analysed in each particular case.

The following image shows the same building plan with four scanners (grey boxes hanged on the walls), which could be four LCSBC.

Locating the scanners in the building and calibrating the IPS, any element equipped with a beacon advertiser can be scanned by the system. In our case, the elements to be positioned in the building will be people, each one carrying a beacon advertiser. These devices emit BLE signals that can be captured by the scanners and so, each particular element in the building can be located by the system.

In our proposal, the scanners publish the captures to a general log. A service capable of positioning each element using the captures will be subscribed to this general record. To build the proposal, we will analyse different factors such as the most appropriate beacon protocol, the most suitable LCSBC, the best IoT protocol for our IPS, the positioning accuracy or the technology stack to be used.

In order to carry out the analysis of these issues, we are currently developing PANAL ( from Position ANALyzer) the Spanish term for honeycomb. We will write about this resource in the coming weeks.

PANAL is currently a set of Eclipse Kura components that will allow us to i) configure an LCSBCs either as a beacon scanners or as a beacon advertiser by using different protocols (Eddystone and iBeacon), ii) build datasets, iii) test different positioning algorithms, iv) measure the positioning accuracy and v) calibrate the IPS.

In the next post, we will continue explaining the pillars of our proposal, addressing one of the most interesting and challenging issues, how we are going to approach the construction of a Trusted IPS.