IOTA Hack Gdańsk and my application created during it - IOTA Sensors

Hackathon

In the middle of November, at Gdańsk, there was a first IOTA hackathon in Poland. It was organized by Baltic Data Science and Datarella and sponsored by Bright Inventions, IOTA and Crowdstart Capital. The goal of this hackathon was to improve, test, extend or use IOTA Tangle. It started at Friday 17-th and ended at Sunday 19-th November.

IOTA Tangle

OK, so what is this IOTA Tangle? The Tangle is directed acyclic graph which is used as distributed ledger. It is similar to blockchain, but has some additional features, so it probably can't be called blockchain clone. IOTA was designed with Internet Of Things in mind, so transactions within it should be quick, cheap and not compute intense. And they are so, at least in theory.

When I come to IOTA hackathon the only knowledge about IOTA was that it has two types of wallets - full and light. Full has to be run on public ip address, and light can just connect to full wallet. But during hack I found some quite interesting properties of IOTA Tangle.

First property I learned, was that there is no fee for sending message/tokens. Yes, in opposite to Bitcoin blockchain, there is no need (or even possibility) to pay fee for your transaction to be processed with priority. So if you would like to pay for coffee with IOTA tokens, you theoretically should be able to do that without paying another few dollars for your transaction to complete within minutes/seconds. Seems cool.

Second property (which I also think is cool) is that, if you would like to attach your transaction to tangle, you have to validate two other pending transactions. By validating I mean to do some simple calculations on your side. It means more or less, that with each potential transaction, there are two other potential transactions validated at the same moment. So, with generating more traffic, more traffic is served. It looks like good approach to scalability problem.

Third property, which is probably most interesting, but also most problematic for me, is possibility of creating sub-tangles. Sub-tangle is tangle updated locally by interested parties. For example, if a company owns full node, and company's intranet lost connection to global internet, clients which have connection to intranet, still can create and validate transactions. Later, when node will be able to connect to other internet nodes, it will automatically merge local sub-tangle to mainstream tangle. At least I understand it like that.

Coding

OK, but what practical applications could be built based on IOTA Tangle? Since IOTA is designed to work well in IoT environments, my first idea was to use it to send data from sensors to publicity. And after considering other hack ideas this was my goal.

I decided to work with Python and IOTA module called PyOTA. Since I couldn't find relevant, working and up to date documentation I also helped myself with REST API and urllib2. I divided my project into two "scripts": client and vendor. The idea is simple: client want to buy data point from sensor type in particular location. He identifies interesting wallet binded with sensor and sends to its address, standardized message with token(s) attached. Device with sensors (Raspberry Pi for example) and vendor application, checks for incoming messages and when it find request with tokens, it sends reply message with data.

This is for theory. During hackathon we were using testnet and seed generator which was generating wallet with testnet tokens inside it. IOTA Tangle is built in such way, that you can safely receive as many transactions to walled as you wish, but you can spent only once from it, then remaining amount of tokens it transfered to new wallet address. Since I had problems with implementing handling of this situation in my scripts, I decided to drop paying for data points and I just served all incoming transfers (even without attached tokens).

And that simplification created another problem. Messages without tokens are treated differently than messages with tokens. If you send token, your sender address is included in bundle which is attached to tangle. If you sent message without tokens, it doesn't have sender walled address. So I couldn't easily identify sender. So I decided to attach sender id within message, and compare it known senders addresses in vendor script.

After hours of creating and hacking dirty code, hackathon come to end and I decided to test my creation in multiple clients and one vendor environment. I made decision that latest request will be served first, so if some kind of DDoS situation emerge, vendor will just ignore previous requests.

Tests

My environment varied from 1 to 12 clients and 1 vendor. Communication in testnet worked without problem. Clients were configured to send a request every 20 seconds and vendor was either checking for new messages or was sending response. With 1 client, vendor was able to handle more or less every request. With 2 clients some requests were dropped, but situation wasn't critical. With more active clients, vendor was able to handle 3 requests over 2 minutes.

Conclusion

Performance of data exchange was pretty disappointing - serving request for 40 seconds is quite long for IoT IMHO. It could be probably improved by a) writing optimized code, b) use flash channels (with which I don't have experience yet) and c) switching to production network (or it might get worse?). But on the other hand, it seems that setup of client - vendor communication was quite easy - only needed thing was wallet addresses. And even this could be eliminated when someone figure out how to handle addresses changes. Setup was also part of problem which I would like to solve with IOTA - setup as easy as possible and zero knowledge clients - vendors network. And this looks pretty promising from this point of view.

Future and possible applications

During hackathon I had opportunity to talk with persons which had various experience with blockchains - from zero like me to deployment of blockchain system on live, field tested context (World Food Programme). Based on those discussion I found few possible extensions of my application:

• Create network of public sensors which will continuously publish sensors data.
• Build tangle sensors explorer which will crawl through tangles and look for historically published data.
• Incentivize vendors to exchange data for tokens - for example vendors which are operating in risky/costly areas like war zones, disaster areas etc.
• Create autonomous sensor bot and let people vote with tokens where should it operate - for example rigid airship which will monitor air quality and stream live video for most voted coordinates.
• Add encryption layer for data exchange so enterprises could use private IOTA Tangle messaging over public network. Maybe it is implemented already?

Code

My code and slides are available on GitHub. I didn't do any cleanup, so everything is messy and Jupyter Notebooks (sic) for client and vendor have 13 testnet seeds/wallets hard coded ;). If you are interested in testing it on your own, please write it in comment - I will try to prepare getting started for it.
I didn't prepared any screen shots/concept graphics for it. My code must be enough ;). Eventually you can watch video from Hack finale:

My pitch talk starts at 13:30

Closing notes

In my opinion IOTA Tangle is quite interesting alternative for blockchain. For now, it has some immaturity problems, but when they will be solved, it may change rules on blockchain-like technologies market. And it seems that people are trading IOTA tokens already, for moment of writing (27.11.2017 18:09:18) IOTA/USD price on bitfinex is 0.95375? To be honest I have no idea if it is hype or sign of maturity, time will show.

If you watched finale video, you probably saw talks from other teams, you can read about their outcomes here:

• Freedom Pass
• PlugInBaby
• Blockchain and Liquid Democracy

Big thanks to organizers, sponsors (mentioned above) and all participants. I enjoyed this event very much, I have learned quite a lot about blockchains and tangle and I'm looking forward to build some other cool applications, not only on hackathons ;).