Motivation:
Today, tiny micro controller driven potential IoT devices have to transmit their data to a central IOTA Node [Gateway] to become attached to a transaction bundle, signed and in case of value Tx — PoW is to be done. While actually PoW need to be outsourced e.g. to and service like https://powsrv.io , the signature of a bundle can be calculated on MCU’s. This enables tiny IoT devices to have its own wallet control and data exchange with direct payments between MCU’s. Here the key is transmitting signed IOTA transactions with or without internet access. (e.g. offTangle via flash channels)
But its necessary to reduce the footprint of software implementations running on MCU’s to an minimum. For instance, tiny low end, low energy consuming MCU’s may have no Memory Management Unit beside their CPU. This makes it necessary for any software implementation to avoid dynamic memory addressing. In addition it shall be C99 POSIX compliant to be work with any toolchain and development platform.
The target of this project is to define a concrete IOTA-Software Toolchain for MCU’s by using existing IOTA Modules. All this shall close the gap to m2m economy even without dedicated ternary SoC’s. Multiple MCU-driven wallets shall share data and pay each other for the data they used. Other projects had shown that its possible to sign transactions on µControllers, so attaching zero value MAM Tx or value Tx to the Tangle is the next obvious step.
The Projects Scope & Vision
while IOTA C-Client be the IoT wallet, MAM module is essential to obfuscate data in (zero value) transactions. At least its the IRI or Ict which can provide gateway or permanent node capabilities and it should run on lower end hardware as well.
Now imagine two MCU driven actors, lets call them “MCU device1” and “MCU device2” (can’t see this Alice and Bob examples anymore..:). The MCU device1 will send its signed bundles to an IOTA node (gateway) to be attached to Tangle. When its attached, MCU device1 will check if it’s Tx is confirmed and reattach if necessary. When MCU device1 finds a new Tx from MCU device2 it pays a small amount e.g. 1iota.
MCU device2 acts in same way, so both devices create a simplified voluntary m2m economy on as a base for further extension.
How to approach:
1st Step:
Make the IOTA C-Library running on different MCU platforms to get MCU-Signed transactions on the Tangle.
Make the IOTA C-Client running on different MCU platforms to get MCU-Signed transactions on the Tangle.
Compare resource usage of C-Library and CCLient. This could lead to some contribution to the Entangled project if there is an overall agreement that it makes sense.
Here is an running example with RiotOS + C-Library (iota_transaction_pthread) which needs some extension but shows the basic signature process: https://github.com/Citrullin/RIOT
Actual “iota_transaction_pthread” example describes the calculation process only. It creates an address from seed and does the signature calculations for the bundle.
optional: Benchmark different RTOS variants like RiotOS, Zephyr, … where runtime and ease of use (toolchain, ide integration, …) are measured on STM32 and ESP8266.
Finally, the C-Client for ESP32 example could be the base for next steps. It shows quite nice how to apply the Libraries and API’s from the IOTA Entangled Repository which is officially maintained by IOTA Foundation.
2nd Step:
Convert MAM from JS to C99 POSIX w/o dynamic memory allocation (malloc) and test it on different MCU platforms. Link to MAM lib
Note: There are other MAM Lib’s available who claim to be light weight and fast, also MAM2 in C has been released but needs prove to run on MCU’s…
3rd Step:
Combine IOTA C-Client and MAM C Implementation in way to have MAM obfuscated MCU-Signed transactions attached on Tangle.
Optional Step3.1: Test and optimize alternative Crypto Hash Function compared to actual Keccak implementation.
4th Step:
Attach MAM signed zero value Tx to the Tangle, to obfuscate data from any data source e.g. temperature sensor.
Use optimizations like creating bundles with multiple Tx‘s to reduce number of Tx to track — and potential reattachment later when value Tx is sent. This can be achieved by utilizing the “input_buffer and output_buffer” from the “iota_transaction_pthread” example.
Send value Tx’s to another wallets address and vice versa. Monitor the Tx state by utilizing the IOTA node API. Reattach the Tx after some defined time period if its not confirmed.
Having two MCU devices who attach their obfuscated data to Tangle and and pay each other for being able to read it.
Details how to approach -I-
1.Reproduce
•The IOTA IOTA C-Library has successfully signed transactions on MCU’s by running on different MCU’s (STM32 Blue Pil, ESP32, ESP8266, …). So the first task shall be to reproduce the results and test API examples to get familiar with tools and libs.
•Next, after zero value Tx bundles are signed, its time to attach some zero value Tx to the Tangle. Therefore the code should be ported to ESP8266 and/or ESP32 to send signed bundles via WIFI to an IOTA node and attach to Tangle.
- optional: To make it simple in the beginning its possible to try to host this local test environment. The idea is, just to replace the IOTA light wallet from the tutorial movie, by ESP8266 messages. Now the test environment is could be replaced by IOTA live net.
•When zero value Tx’s attached to IOTA production net an benchmark report is created for the used mcu’s. This will provide some valuable parameters for the upcoming tasks.
2. Extend it step wise
•After this was achieved its time to attach zero value Tx to the live Tangle.
•Now its time to care about value Tx. Currently to do so, prove of work is necessary at the actual state of IOTA protocol. MCU’s are to week to do the PoW in a reasonable time, so it need to be outsourced: https://powsrv.io/
•Now it happens that a value Tx is not confirmed by the network for any reason. This happens from time to time and in this case its possible to reattach the Tx bundle to bring it in contact with recent transactions height to increase the chance becoming referenced. The MCU device just need to track the transactions up to the point were they getting confirmed. After a defined time, still unconfirmed Tx are just reattached. This can be achieved simply by api calls to the IOTA gateway node. The PoW for the reattachment can be outsourced in same way as the origin Tx.
3. Results in a PoC
Finally two (and more) MCU‘s will create a small machine to machine economy based on voluntary payments. This of course is not an industry ready production PoC — but for some applications and communities it could work. But at least it‘s a base from where further development can be stated.
Outcome:
- Provide the created PoC lib’s with documentation in a GitHub repository.
- Provide the final example code, where value Tx and non value Tx where send, with documentation in a GitHub repository.
- Provide a Benchmark Report where all mcu platforms where compared for each single development step.
Outlook
A possible extension of this project could be implementing “flash channels“ on MCU’s in a way that voluntary payment for data become mandatory and trust less. Also temporary direct payments between interconnected MCU devices without permanent internet connection could be achieved with further development in this direction.
Also the problem of storing the seed in a safe way need to be addressed once its proven to work. Already there are some ideas by several community members but the step from idea to realization need to be made.
If you like what you read, go here and hit the Heard: EcoSystem Project Page
Sources and References:
•Possible platforms: ESP32, ESP8266, STM32 xxx, RISC-V open ISA, Arduino
•Entangled Repo: Mono Repository with all necessary lib’s, officially maintained by IOTA Foundation.
•RiotOS workflow: I got the “iota_transaction_pthreat“ example compiled and running on ESP32 with RiotOS utilizing threading and low level stuff. To reproduce it as a starting point, follow the sections here: https://riot-os.org/api/group__cpu__esp32.html
•Zephire RTOS: Zephire is an alternative RTOS to RiotOS: https://github.com/zephyrproject-rtos/zephyr
•IOTA C-Library: C implementation of IOTA Lib to sign transactions on MCU‘s
•IOTA MAM: https://github.com/iotaledger?utf8=%E2%9C%93&q=mam&type=&language=
•IOTA Ict: https://github.com/iotaledger?utf8=%E2%9C%93&q=ict&type=&language=
•IOTA IRI: https://github.com/iotaledger?utf8=%E2%9C%93&q=iri&type=&language=
•General Support and Ressource: https://discordapp.com/invite/fNGZXvh
From this paper here its getting clear why we need to use a particular topology of actors.
short version:
complete paper:
http://user.it.uu.se/~atiel485/iota-iot-2018.pdf
Here is another excellent piece of work which explains the actual state of implementations:
https://medium.com/@punpck/iota-crypto-core-fpga-1st-progress-report-caebe1dac579
