Parallelizing IOTA transactions in Kura

Is it necessary to store 10, 100 or 1000 locations per minute in the tangle? Now we can. How? Using IOTA’s workers.

2 comments

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>.

workers.png

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.

teamwork

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 😉

2 comments on “Parallelizing IOTA transactions in Kura”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s