Die IOTA-Kernfunktionen wie Adressgenerierung, Signierung und Proof of Work (PoW) benötigen viel Rechenleistung, was es praktisch unmöglich macht, dass diese Funktionen von den Ressourcen armen kleinen [I] embedded Systemen im IoT ausgeführt werden können. Auch für Geräte mit einem hohen Transaktionsvolumen, wie beispielsweise Fertigungsmaschinen, die jeden Arbeitsschritt protokollieren, kann dies ein Problem werden. Daher wird eine Hardwarelösung gesucht, die eine sehr hohes Transaktionsvolumen schnell und energieeffizient bewältigen kann.
Ein Asic (application-specific integrated circuit) ist eine anwendungsspezifische integrierte Schaltung auch Kunden Chip genannt. Asics unterscheiden sich von anderen Mikrochips, da sie in der Regel nach Kundenanforderung und speziell für ein embedded System gefertigt werden. Bei der Herstellung eines Kunden Asic, entstehen durch die Kundenspezifischen Anforderungen zunächst hohe Einmalkosten, dafür sind die Herstellungskosten pro Stück in der Massenproduktion geringer. Die Funktion eines Kunden ASICs wird bei der Herstellung fest programmiert und kann im Nachhinein nicht mehr ohne weiteres verändert werden.
[I] Ein embedded system ist ein binärwertiges digitales System (auch Computersystem genannt), das in ein umgebendes technisches System verbaut ist und mit diesem in Wechselwirkung steht. Dabei übernimmt der Rechner meist Überwachungs-, Steuerungs- oder Regelungsfunktionen, ist oft aber auch für eine Form der Daten- bzw. Signalverarbeitung zuständig.
Crypto Core FPGA
Das Projekt „Crypto Core FPGA“, welches auch aus dem IOTA EcosystemDevelopment Fund mit 59.100$ unterstützt wird möchte die Probleme der energieeffizienten Ausführung der IOTA-Kernfunktionen und der ternären Ansteuerung von binären Asics auf Hardwarebasis beseitigen. Federführend bei diesem Projekt ist der Hard- und Softwarespezialist Thomas Pototschnig (in der Community als MicroEngineer bekannt), er ist auch Mitbegründer des PoWaaS-Startups powsrv.io (PoW-as-a-Service).
Ziel seines Projekts ist es, mehrere Module zu entwickeln, um bestehende oder neue Embedded-Systeme (mit Asics) in die Lage zu versetzen, IOTA-Kernfunktionen auf eine schnelle, sichere und energieeffiziente Weise auszuführen. Weil der gleiche Code später als ASIC bereitgestellt werden kann, werden bei der Entwicklung von Asics, dessen Funktionen zuvor in Testsystemen geprüft, das sind zumeist FPGAs.
Das erste Modul ist ein IOTA-Core-FPGA-Modul, das die meisten IOTA-Core-Funktionen mit Hardwarebeschleunigung versorgt. Es bietet eine benutzerfreundliche High-Level-API, während rechenintensive Low-Level-Berechnungen auf eine spezialisierte Logik verlagert werden, die im Vergleich zu einer reinen Softwarelösung einen erheblichen Geschwindigkeitsvorteil bietet und sich somit perfekt für eingebettete Anwendungen eignet. Zusätzlich implementiert das FPGA-Modul mehrere Sicherheitsmechanismen, die es Angreifern sehr schwer machen, unbefugt auf die im Modul gespeicherten Seeds zuzugreifen.
Das zweite Modul ist ein System-on-Module (SoM), dass das zuvor beschriebene FPGA-Modul verwendet. Dieser SoM wird Linux ausführen und verfügt über genügend Ressourcen, um eine große Anzahl von Anwendungen ausführen zu können. Das SoM könnte als ein Integrationsbeispiel für das FPGA-Modul angesehen werden. Es kann unverändert für eigene Anwendungen verwendet werden, aber auch andere Mikrocontroller können das FPGA-Modul problemlos verwenden.
Das dritte Modul ist eine Anwendungsplatine, die das SoM verwendet und ein IOTA-Sensor-Gateway für einfache (dumme) Sensoren.
Übersicht über die Meilensteine in diesem Projekt
Meilenstein 1: PiDiver Proof-of-Work
Der erste Meilenstein war der PiDiver, diese Entwicklung fand bereits statt, bevor Thomas die Finanzierung des Projektes durch den Ecosystem Fund bestätigt bekommen hat.
Bei dem PiDiver geht es um die Entwicklung eines Hardwarebeschleunigers für die effiziente Durchführung von PoW auf Embedded Systems und Low-End-PCs, wie beispielsweise einem Raspberry Pi. Da sich bereits sehr viele Raspberry im Umlauf befinden und die Anschaffungskosten sehr günstig sind, kann IOTA enorm davon profitieren, wenn diese Raspberry IOTA PoW effizient durchführen können. Darüber hinaus kann der PiDiver nicht nur von Raspberry, sondern auch von High-End-PC-Systemen (z.B. mit Atom-CPU) verwendet werden, da er direkt mit USB verwendet werden kann, somit bietet der PiDiver auch eine Hardwarebeschleunigung für Full-Nodes mit weniger leistungsstarker CPUs.
Technische Details: IOTA PoW benötigt viel Rechenleistung, was das Senden von Transaktionen auf kleineren Mikrocontrollern (wie ARM) sehr langsam macht. Einer der Hauptgründe ist, dass die innerst-Schleife von Curl-P81 auf Universal-CPUs nicht sehr effizient berechnet werden kann. Selbst moderne CPUs mit SIMD-Erweiterung (wie SSE oder AVX) sind in Bezug auf echte parallele Berechnungen stark eingeschränkt.
Der PiDiver archiviert ca. 15,8 MHz und ist in der Lage, PoW ca. 5,8-mal schneller durchzuführen als die SSE-optimierte dcurl-Bibliothek auf einem Quad-Core-i5-PC, benötigt dabei aber nur 2 statt 100 Watt. Statistisch gesehen sind 25% aller Nonces in 87ms, 50% in 200ms und 75% in 422ms zu finden. Das ergibt durchschnittlich 3,33 TX/s oder 0,66 TPS (Bundle mit 5TX).
Im Vergleich zu einem herkömmlichen Raspberry Pi ist das eine Beschleunigung von >200.
Dieses Projekt ist vollständig Open Source und wird unter der MIT-Lizenz lizenziert. Alle Informationen (Quellcodes, Schaltpläne, Layouts, Software) stehen zum kostenlosen Download zur Verfügung.
Meilenstein 2: IOTA Krypto FPGA Kern und Arty S7 HAT
Der zweite Meilenstein war die Entwicklung eines FPGA-Kerns, der die meisten IOTA-Kernfunktionen mit Hardwarebeschleunigung versorgt. Es bietet eine High-Level-API, die einfach zu bedienen ist, während rechenintensive Low-Level-Berechnungen in eine spezielle Logik ausgelagert werden, was einen erheblichen Geschwindigkeitsvorteil gegenüber einer reinen Softwarelösung bietet.
Für diese Arbeiten wurde ein handelsübliches Arty S7-Board verwendet und es wurde ein HAT-Platine (aufsteckbare Zusatzplatine) entworfen. Auf der HAT Platine befindet sich ein Secure-Element, SPI-Flash (wurde nie verwendet) und einen W5500 Ethernet-Controller.
Innerhalb des FPGA läuft eine Cortex M1 (ARM) Soft-CPU (@ 100MHz), die in C/C++ programmiert werden kann. Die Firmware ist durch Sicherheitsmechanismen des FPGAs geschützt. Es sollte für Angreifer schwierig sein, sich unbefugt Zugang zu Seeds zu verschaffen – die in einem sicheren Speicher abgelegt sind – oder die Firmware zu manipulieren.
Ebenfalls innerhalb des FPGA gibt es eine spezielle Logik, die das Hashing (Curl-P81 (und PoW), Keccak384 (verwendet in Kerl) und Troika) und die Typkonvertierung (binär <-> trinary) beschleunigt. Diese speziellen Logikblöcke werden als Hardware-Beschleuniger bezeichnet und bieten einen großen Leistungsschub (Hash >150) im Vergleich zu reinen Software-Implementierungen. Diese Lösung ist schneller als Hashing auf einer PC-CPU mit z.B. 3GHz.
Die FPGA-Kern Muduk kann folgende Aufgaben ausführen:
- integrierter Cortex M1 (32Bit ARM mit 100MHz Takt), der in C / C ++ programmierbar ist. Es kann auch über eine Standard-Debugging-Schnittstelle (SWD) getestet werden.
- Es verfügt über Beschleuniger für Trinary <-> Binary-Typ-Konvertierungen, Hashing (CURL-P81, KECCAC384, Troika; einzelner Taktzyklus pro Hashing-Runde) und kann sehr schnell Proof-of-Work ausführen (durchschnittlich ~ 330 ms).
- Es verwaltet Seeds und kann bis zu 8 Seeds in einem sicheren Speicher ablegen
- Es bietet eine JSON-API, die über RS232 verwendet werden kann. Derzeit bietet es Befehle zum Generieren von Adressen oder zufälligen Seeds, zum Signieren von Transaktionen und PoW – alles ist hardwarebeschleunigt.
- alles läuft im FPGA und die Konfigurationsdatei des FPGA kann verschlüsselt werden. Es ist sehr einfach, die FPGA-Konfiguration zu aktualisieren, aber es ist unmöglich, den Mikroprozessorcode (der als ROM eingebettet ist) zu manipulieren oder vertrauliche Informationen wie Schlüssel zu extrahieren. *: In Sachen Sicherheit gibt es kein „Unmöglich“. Der Verschlüsselungsalgorithmus AES128 ist jedoch ungebrochen.
Installationsanleitung (en): https://gitlab.com/iccfpga/iccfpga-core/wikis/iccfpga_install
Informationen zur HAT Platine (en): https://gitlab.com/iccfpga/iccfpga-core/wikis/hat, PCB Daten /Gerber, Bom usw.): https://gitlab.com/iccfpga/arty-s7-hat
Meilenstein 3: FPGA-Modul
Das FPGA-Modul wurde für den FPGA-Core aus Meilenstein 2 entwickelt.
Was ist ein FPGA?
FPGA ist eine Abkürzung für “Field Programmable Gate Array”. Digitale Logik kann in einer Hardwarebeschreibungssprache wie VHDL oder Verilog beschrieben werden und Synthesewerkzeuge können aus diesen Beschreibungen digitale Hardware synthetisieren.
Einfach beschrieben, könnte man es so sehen: CPUs führen Programme aus. Ein FPGA kann so konfiguriert werden, dass es z. B. CPUs ausführt, die Programme ausführen.
FPGAs werden häufig zum Prototyping von Hardware verwendet, die später zur Herstellung von ASICs (Real Chips) verwendet werden kann. ASICs sind viel schneller und benötigen weniger Energie, sind jedoch immens teuer in der Herstellung. Zudem müssen diese bei Änderungen, wie zum Beispiel ein neuer Hashalgorithmus, komplett neu entwickelt und hergestellt werden.
FPGAs können einfach neu konfiguriert werden, da die Konfiguration flüchtig ist. Mit jedem Einschaltzyklus wird die Konfiguration erneut in das FPGA geladen. Viele FPGAs unterstützen auch die Verschlüsselung. Dies bedeutet, dass die Konfiguration verschlüsselt werden kann und das FPGA nur Konfigurationen akzeptiert, die durch im FPGA gespeicherte (flüchtige oder permanente) Entschlüsselungsschlüssel entschlüsselt werden können. Dies kann als Kopierschutz oder Schutz gegen Manipulation oder Analyse der Konfiguration verwendet werden.
Was ist das FPGA-Modul?
Während im zweiten Meilenstein der FPGA-Kern (Konfiguration) für den FPGA entwickelt wurde, ging es in diesem Meilenstein um die Entwicklung eines FPGA-Moduls, das den FPGA-Kern verwendet. Beide zusammen können als sicherer Kryptoprozessor mit Hardwarebeschleunigung für Algorithmen angesehen werden, die häufig in IOTA verwendet werden.
Nachfolgend ein Größenvergleich des Moduls mit einer 1EUR Münze.
Technische Details:
- XC7S50 (FBGA196-Gehäuse Bauform) Spartan 7
- Größe 30x26mm
- Highly integrated step-down converter
- 128MBit SPI Flash (wird auch zur Konfiguration des FPGAs verwendet)
- Microchip ATECC608A Sicherheits-Element
- Ersatzpins oben auf dem Modul (16 I / Os)
- Mehrere Pins auf den Modulstecker gelegt (25 I / Os + JTAG)
- In Kombination mit dem FPGA-Kern aus dem zweiten Meilenstein werden die E / A-Vorgänge auf dem Modulanschluss wie folgt verwendet:
- JTAG für das FPGA
- SWD-Debugging-Schnittstelle für den Cortex M1-Prozessor, der im FPGA ausgeführt wird
- RESET für den Cortex M1
- Master-SPI mit zwei dedizierten E / As für einen W5500-Ethernet-Controller
- Master-SPI (derzeit nicht verwendet – möglicherweise wird es ein SPI-Slave als schnellere Alternative zu UART)
- UART (115,2 kBaud)
- 4 Ein- und 4 Ausgänge
- Darüber hinaus befinden sich im Modul 16 nicht verwendete E / As.
Das Repository für das FPGA-Modul finden Sie hier: https://gitlab.com/iccfpga/iccfpga-module
Meilenstein 3: DEV-Board für FPGA-Modul
Zusätzlich wurde ein “dev” -Board entwickelt. Es wurde zum Testen des FPGA-Moduls und auch zum Testen von anderen Dingen wie dem Bootstrapping des FPGA ohne proprietäre Tools benötigt. Es kann eigenständig (zusammen mit dem FPGA-Modul) ausgeführt werden, da sich auf der Karte ein Ethernet-Controller befindet.
Repository für Dev-Board: https://gitlab.com/iccfpga/iccfpga-dev-board
Hinweise zum Zusammenbau: https://gitlab.com/iccfpga/iccfpga-core/wikis/dev
Meilenstein 4: Linux SoM (System-on-Module)
Ein weiterer Teil war ein SoM , dass das FPGA-Modul nutzen konnte. Ursprünglich war ein etwas größerer Mikrocontroller geplant, aber er wurde durch einen leistungsfähigeren Mikrocontroller ersetzt, der in der Lage ist, Linux mit vollem Main-Line-System zu betreiben. Es hat auch 128MB RAM, was es für viele Anwendungen geeignet macht.
Das Herzstück des SoM ist der ATSAMA5D27-Mikrocontroller von Atmel / Microchip, er unterstützt viele Sicherheitsfunktionen. Zum Beispiel kann jeder Teil der Boot-Kette signiert und verifiziert werden. Außerdem wird die direkte Hardware-Verschlüsselung des externen QSPI-Flash-Speichers unterstützt, sodass der Linux-Kernel verschlüsselt gespeichert werden kann, ohne die Systemleistung zu beeinträchtigen. Es verfügt auch über einen internen sicheren Speicher, der durch einen externen Manipulationsschutz-Pin ausgelöst werden kann. Es verfügt über die TrustZone von ARM zusammen mit Hardwarekryptographie, RSA/ECC, Speicher-Verschlüsselung, unabhängigem Watchdog, Temperatur-, Spannungs- und Frequenzüberwachung und einer eindeutigen ID in jedem Gerät.
Ein weiterer Vorteil ist der sehr geringe Stromverbrauch – unter 1 / 2W bei voller Geschwindigkeit. Atmel behauptet, es sei der niedrigste Stromverbrauch aller SoCs (System on Chip), die unter Linux laufen können. In Kombination mit einem PMIC (Power Management IC) unterstützt es die dynamische Spannungsskalierung – das heißt, es kann seine eigene Kernspannung im IDLE-Modus reduzieren, um den Stromverbrauch noch weiter zu senken. Es werden auch mehrere Schlafmodi bis in den µA-Bereich unterstützt. Eine externe Unterbrechung oder die Echtzeituhr (RTC) kann den Mikrocontroller aufwachen lassen.
Es ist vorstellbar, dass dies die Tür zu einem stromsparenden und kostengünstigen Bee-Node öffnet und sich dieser Aufbau zu einer Referenzhardware für IOTA entwickelt.
Technische Details:
- Cortex A5 SoC mit 500 MHz, 128 MB integriertem DDR2-RAM und vollständiger Linux-Unterstützung
- Sockel für das IOTA Crypto Core FPGA-Modul
- 8 MB QSPI-Flash (On-the-Fly-Verschlüsselung wird unterstützt)
- 10/100 MBit Ethernet
- High-Speed USB Host + Device
- µSD-Card-Schnittstelle
- mehrere Schnittstellen (I2C, SPI, UART)
- Größe von 83x36mm
Repository: https://gitlab.com/iccfpga/iccfpga-som
Hinweise zur Herstellung / Montage: https://gitlab.com/iccfpga/iccfpga-core/wikis/sommodule
Linux Installation: Link
Meilenstein 5: Gateway
Um den Linux SoM zu nutzen, wurde ein Gateway-Board entwickelt. Es machte die meisten Peripheriegeräte zugänglich und lieferte zusätzliche drahtlose Schnittstellern. Ursprünglich hätte das Gateway eine Beispielanwendung für das Linux-Modul sein sollen, aber es hat jetzt mehr Funktionen als ursprünglich geplant.
Ein Gateway braucht Konnektivität, also hat es mobiles Internet (ublox sara g340), Wi-Fi, Bluetooth und 10/100MBit LAN. Weil unter anderem auf dem SoM ein vollständiges Linux läuft, gibt es auch einen USB-Host und einen Geräteanschluss auf der Gateway-Platine. Zusätzlich befindet sich auf der Platine ein Mini-DIN-Stecker, auf den theoretisch ein LoRaWAN Konzentrator aufgesteckt werden kann. Das bedeutet, dass Pakete von verschiedenen Endgeräten mit unterschiedlichen Spreizfaktoren können auf bis zu 8 Kanälen parallel empfangen werden.
Die letzte Schnittstelle ist etwas speziell, da sie fast nicht mehr verwendet wird. Es ist IrDA. Der Hauptgrund für die Verwendung von IrDA auf dem Board ist, dass es für die einfache, kostengünstige und sichere Kopplung von Geräten wie LoRaWAN-Sensoren verwendet werden kann. Ein LoRaWAN-Sensor besteht im Wesentlichen aus einem LoRaWAN-Funkmodul und einem Mikrocontroller wie STM32. Obwohl IrDA nicht mehr sehr verbreitet ist, unterstützt das STM32 es immer noch direkt. Zusätzlich wird nur eine aktive Komponente (IrDA-Transceiver) benötigt.
Das Gateway könnte Sensoren unterstützen.
über Bluetooth verbunden
verbunden über LoRaWAN (liegt nicht im Rahmen des Ecosystem Projekts)
lokal verbunden auf SPI oder I2C
verbunden über Ethernet/Internet (ich weiß, das ist lahm^^^)
Technische Details:
- UBlox Sara G340 für mobiles Internet
- Wi-Fi, Bluetooth
- 10/100 MBit LAN
- Highspeed Host + Gerät
- Mini DIN 8 mit SPI, I2C (konfigurierbar)
- IRDA
Repository: https://gitlab.com/iccfpga/iccfpga-gateway
CO2-Sensor
Der CO2-Sensor ist ein reiner Mustersensor, der die Machbarkeit des gesamten Gateway-Konzepts zeigt.
Diese Sensorplatine war nicht Teil des Ecosystem Development Fund Vorschlags. Thomas benötigte zum Testen aber einen, daher baute er sich kurzerhand einen zusammen. Die Wahl fiel auf ein nRF52 Modul (UBlox NINA B112), einen CO2 Sensor (Sensirion SCD30) und ein E-Paper Display (Waveshare). Das SEHR Schöne an nRF52 ist, dass sie wie jeder andere Cortex M basierte Mikrocontroller programmiert werden können! So benötigte der Sensor nur das UBlox-Modul als Hauptprozessor und Bluetooth (BLE) kam kostenlos dazu.
Im obigen Bild ist der Sensor ist über BLE (Bluetooth Low Energy) und Low6pan (IPv6 via Bluetooth) mit dem Gateway verbunden und veröffentlicht MQTT-Pakete. Eine auf dem Gateway ausgeführte Software abonniert das MQTT-Thema und verwendet das FPGA-Modul zum effizienten Erstellen von IOTA-Datentransaktionen, die dann an das Tangle gesendet werden.
Repository: https://gitlab.com/iccfpga/co2-sensor
Endergebnis: Alle Baugruppen zusammengesetzt
Nebenprojekte – die ursprünglich nicht im Ecosystem Development Fund Antrag geplant waren.
Troika
Ende Dezember 2018 wurde von der IF der neue leichte Hash-Algorithmus „Troika“ angekündigt. Obwohl nicht im Ecosystem Development Fund Budgetplan enthalten, wurde eine FPGA-Implementierung für Troika in zwei Versionen entwickelt. Eine Hochgeschwindigkeitsimplementierung (1 Takt pro Hashing-Runde) für das IOTA Crypto Core FPGA und eine langsamere Variante für günstige $5 FPGAs (Bild unten).
Des Weiteren wurde auch eine SIMD-Version (bis AVX256) implementiert, mit der mehrere Hashes auf einmal gehasht werden können. Es wird sich in Zukunft noch herausstellen, ob es von Nutzen ist oder nicht.
MAM
Hinweis: MAM wurde mittlerweile in IOTA Streams umbenannt, ich lasse aufgrund der Bezeichnung in den Bildern auch MAM im Artikel stehen.
Die Architekturübersicht enthielt von Anfang an MAM, aber diese Funktion spielte für dieses Projekt eigentlich keine Rolle. Zum Teil, weil das neue MAM noch nicht fertig programmiert war und auch, weil nicht klar war, ob und in welchem Teil MAM auf dem FPGA laufen würde.
Der Cortex M1 verfügt über sehr begrenzte Ressourcen (128kB ROM, 128kB+40kB RAM). Es waren erst die letzten Tage des Projekts, in denen versucht wurde, MAM auf dem FPGA-Modul zum Laufen zu bringen. (deshalb wurde das Ende des Projekts um 3 Tage verschoben)
Es hat funktioniert…. Natürlich ist dies nur ein Proof-of-Concept und es konnte nicht viel Zeit in diese Entwicklung investiert werden, aber es zeigt, dass es möglich ist und es schnell genug ist, um praktisch nutzbar zu sein. MAM kann vom Troika-Beschleuniger sehr viel profitieren.
Im unten stehenden Bild sind Benchmarks des Cortex M1 mit und ohne Hardware-Beschleunigung und einer 3,4GHz i5 CPU abgebildet:
Die Hardware-Beschleunigung bietet einen Geschwindigkeitsvorteil von etwa 148 gegenüber einer reinen Software-Implementierung auf dem Cortex M1 und kann (fast) mit meinem i5 mithalten – mit einem Leistungsanteil (<1W) und nur 100MHz.
Zukünftige Arbeit
Diese ganze Arbeit die Thomas in diesem Projekt geleistet hat, war mehr oder weniger nur ein Machbarkeitsnachweis und es wird sich herausstellen, welche Teile häufiger verwendet werden als andere, aber das Ergebnis ist eine gute Grundlage für die weiteren Entwicklungen.
Zitat Thomas: „Meiner Meinung nach gefällt mir das FPGA-Modul am besten, weil es sich sehr gut in IoT-ähnlichen Standalone-Anwendungen einsetzen lässt. Es bietet eine Menge Hashing-Power, für die normalerweise eine PC-CPU benötigt wird, die aber nur einen Bruchteil der Leistung benötigt. Es ist in C/C++ frei programmierbar und durch Sicherheitsmechanismen (wie FPGA-Bitstream-Verschlüsselung) geschützt. Es verfügt auch über einen sicheren Speicher für die Lagerung von Seeds. Das FPGA-System ist sehr flexibel. Bei Bedarf an anderer Peripherie kann das System entsprechend angepasst werden.
Was ich jedoch ändern würde, wäre definitiv, die Cortex M1 Soft-CPU loszuwerden (die Lizenzierung von ARM ist suboptimal) und sie durch einen (wirklich) kostenlosen RISC V zu ersetzen. ARM vergibt die Lizenzen für die IP-Soft-Cores des Cortex M1 kostenlos, aber kein Teil ihrer IP-Soft-Cores darf in Open-Source-Code Repositories enthalten sein. Es war also ein ziemlicher Aufwand, die Lizenzierung zu umgehen – z.B. Anweisungen zu schreiben, wie man von der ARM-Website herunterladen und anschließend Quelldateien für das FPGA-Projekt patchen kann.
Dokumentation
Die Dokumentation finden Sie hier: https://gitlab.com/iccfpga/iccfpga-core/wikis/home
Alle Repositorien hier: https://gitlab.com/iccfpga
Fazit
Dies ist ein sehr wichtiger Baustein und wird den Weg für reale IoT-IOTA-Anwendungen ebnen, die vorher (im praktischen Sinne) nicht umsetzbar waren.Thomas Pototschnig hat herausragende Pionierarbeit geleistet und wenn es einen IOTA-Supporter-Orden geben würde, hätte Thomas ihn definitiv mehr als verdient.
Wer Thomas für seine wichtige Pionierarbeit ein Trinkgeld zukommen lassen möchte, der sollte dies über den Donate Button auf der IOTA-Ecosystem Webseite tun.