24. Jun 2020
Pay-Per-Use Geschäftsmodelle in der Industrie – erste Schritte mit der EOSIO Blockchain

Posted at 06:36h in Insights by Björn Hein

In der vierten industriellen Revolution werden bestehende Geschäftsmodelle auf den Kopf gestellt. Wer weiterhin erfolgreich sein will, muss mithilfe neuer Technologien am Puls der Zeit bleiben und neue Geschäftsmodelle für sich finden. Von bekannten Cloud-Anbietern wie Azure und AWS kennt man bereits Service-getriebene Geschäftsmodelle wie etwa Pay-Per-Use. Betrachtet man im industriellen Umfeld die Maschinen und ihre Komponenten viel mehr als eine dynamische anstatt einer statischen Zusammensetzung, kann man Parallelen zur Cloud ziehen. Durch die Vernetzung sämtlicher Komponenten in einer Fabrik ist es wichtig, eine herstellerneutrale und interoperable Plattform zur Kommunikation zwischen den Komponenten und zum sicheren Speichern von Daten aufzubauen. Genau da kommt die Blockchain ins Spiel.

In diesem Blogeintrag gehen wir darauf ein, wie man mit Hilfe der EOSIO Blockchain einen Prototyp zur nutzungsbasierten Abrechnung von Services im industriellen Umfeld implementiert.

Der konkrete Use-Case

Im Pay-Per-Use Geschäftsmodell kaufen die Maschinenbetreiber die Maschinen vom Hersteller nicht mehr, sondern bezahlen nur noch für die tatsächliche Nutzung. Das bringt einige Vorteile sowohl für den Betreiber, als auch für den Hersteller. ¹

Das Leistungsspektrum kann von einer einfachen Drehung eines Motors bis hin zu einem komplexen digitalen Service reichen. Nun besteht eine Anlage in einer Fabrik aber aus mehreren einzelnen Maschinen und diese wiederum aus mehreren Komponenten verschiedener Hersteller. Diese interagieren miteinander und nehmen gegenseitig Services in Anspruch. Das bedeutet, dass diese Komponenten sich untereinander ebenfalls das Geleistete in Rechnung stellen. Eine Komponente könnte eine Maschine sein, aber auch ein winziger Sensor.

Für unseren Prototyp fokussieren wir uns auf eine exemplarische Komponente: ein Motor, der Umdrehungen als Service anbietet. Aber wie lässt sich die Abrechnung dieser Leistung sicher speichern?

Warum Blockchain?

Würde jeder Hersteller seine Daten bei sich speichern und zu einem gewissen Zeitpunkt bei all seinen Kunden
abrechnen, dann hätte das Nachteile. So könnte beispielsweise niemand überprüfen, ob der Hersteller tatsächlich richtig abrechnet und seine Kunden nicht betrügt. Daraus ergibt sich ein zentrales Problem, welches die Distributed Ledger Technologien (DLT) zu lösen versuchen: Vertrauen zu etablieren, wo keines existiert. Da es hier ums
Finanzielle geht, gibt es meist kein volles Vertrauen zwischen Hersteller und Betreiber.

Die DLT, und somit auch die Blockchain, etablieren nicht nur Vertrauen durch Konsens-Algorithmen und
kryptographische Verfahren, sondern bieten auch den Vorteil, dass sie dezentral aufgebaut sind. Es gibt also keinen
Single-Point-of-Failure. Wenn also mal ein Hersteller entscheidet, dass er sich nicht mehr daran beteiligen möchte oder wenn ein Server einen technisches Ausfall hat, existieren die Daten immer noch verteilt bei allen anderen beteiligten Parteien.

Die wichtigsten Eigenschaften, die die Blockchain für unseren Use-Case bietet, sind also Folgende:

Dezentrale Datenspeicherung
Fälschungssicherheit
Nachvollziehbarkeit

Dazu kommen noch andere Vor- und Nachteile, auf die wir aber an dieser Stelle nicht weiter eingehen.

Wie man eine Dapp entwickelt

Zu Beginn ist es wichtig zu wissen, welche Technologien man für seine App einsetzen wird. Die finale Auswahl hängt
stark vom Einsatzzweck ab, denn jede Technologie hat unterschiedliche Stärken und Schwächen. Im Folgenden haben wir uns für die EOSIO Technologie entschieden.²

Sie ist die zugrunde liegende Technologie für die Kryptowährung EOS und wird von der Firma block.one als opensource Projekt entwickelt. Das Initial Coin Offering ging ein ganzes Jahr lang und hält mit 4,1 Milliarden USD eingespieltem Erlös einen Rekord. Die Entwicklung der Blockchain-Software, sowie Investitionen in EOSIO Startups werden dadurch finanziert.

EOSIO ist grundsätzlich sehr modular aufgebaut und bedient sich dem Plugin Entwurfsmuster. So ist es relativ einfach für Entwickler, die Software für die Knoten (genannt nodeos) im Blockchain-Netzwerk an ihre Wünsche anzupassen. Aber auch die Softwarearchitektur der Smart-Contracts auf der Blockchain ist stark modularisiert. An sich hat EOSIO einen Delegated Proof of Stake Konsens-Mechanismus. ³ Dieser ist wiederum durch sogenannte System-Smart-Contracts implementiert. Es bleibt den Entwickelnden also selbst überlassen, ob sie diesen oder andere verwenden wollen.

Smart-Contract

Der Smart-Contract zu unserem Use-Case speichert Anfragen an den Motor mit einer gewissen Anzahl von Umdrehungen. Diese Anfragen können dann vom Motor abgearbeitet und als eingelöst deklariert werden. Ein Service-Anfrage hat somit folgenden Zustand:

Service { buyer, seller, amount, state = (BOUGHT|REDEEMED) }

Und kann mit den beiden Transaktionen buy und redeem verändert werden.

buy(buyer, seller, amount): id

Es wird eine neue Instanz der Anfrage auf der Blockchain erstellt. Der buyer bestellt amount Umdrehungen von seller. Die Transaktion gibt eine einzigartige ID der Instanz zurück.

redeem(id, seller)

Dadurch wird eine Anfrage an den seller mit einer id eingelöst.

Die Smart-Contracts auf EOSIO laufen auf WebAssembly (WASM). EOSIO unterstützt offiziell zwar nur C++, da es mittlerweile viele Kompilierer gibt die nach WASM übersetzen, hat man eine große Auswahl an möglichen Programmiersprachen. Wir haben uns dazu entschieden, den Smart-Contract in Rust zu schreiben. Dazu findet man auf GitHub auch bereits ein auf Rust portiertes SDK zum Entwickeln von EOSIO Smart-Contracts. ⁴

Implementierung in Rust

Wir erstellen mit cargo eine neue library.

$ cargo new --lib smartcontract

Um die Library später nach WebAssembly zu kompilieren, definieren wir den Typ der Library in unserer Cargo.toml. Außerdem geben wir unsere Dependencies zum EOSIO SDK dort an.

[lib] crate-type = ["cdylib"] [dependencies] eosio = "^0.3.1" eosio_cdt = "^0.3.1" [profile.release] lto = true

In unserem Einstiegscode lib.rs importieren wir zuerst das EOSIO SDK. Dieses stellt wichtige Traits und Makros bereit, die die API von EOSIO widerspiegeln.

use eosio::*; use eosio_cdt::*;

Wir definieren uns die Struktur unserer Service-Anfrage.

#[derive(NumBytes, Read, Write)] struct Service { id: u64, buyer: AccountName, seller: AccountName, amount: u64, redeemed: bool, }

Das Struct implementiert die Traits NumBytes, Readund Writevom EOSIO SDK, damit dies später in die Blockchain serialisiert werden kann. Der Typ AccountName kommt aus den EOSIO SDK und repräsentiert einen Account im Blockchain-Netzwerk.

Die Tabelle-Implementierung wird mit dem Trait Tableaus dem SDK realisiert. Dadurch kann das struct Service in Form einer Tabelle auf der Blockchain serialisiert werden.

impl Table for Service { const NAME: TableName = TableName::new(n!("service")); type Row = Service; fn primary_key(row: &Self::Row) -> u64 { row.id } }

Damit geben wir an, dass die Service-Instanzen in einer Tabelle auf der Blockchain gespeichert werden können und der Primär-Schlüssel auf das Attribut id gemappt wird.

Eine Aktion für den Smart-Contract selbst definiert man als Funktion.

#[eosio::action] fn buy(buyer: AccountName, seller: AccountName, amount: u64) { require_auth(&buyer); let smart_contract_account = current_receiver(); let table = Runtime::table(smart_contract_account, n!("global")); let id = table.available_primary_key().expect("There must be an available primary key!"); let runtime = Runtime { id, buyer, seller, amount, redeemed: false }; table.emplace(smart_contract_account, runtime).expect("Could not emplace new bought service."); }

Wir überprüfen zuerst, ob der Account von buyer auch dem Account entspricht, mit dem die Transaktion getätigt wurde. Dies ist wichtig und verhindert, dass eine fremde Maschine eine Anfrage im Namen einer anderen Maschine erstellt. Anschließend besorgen wir uns die bereits gespeicherte Tabelle, lassen uns die nächste verfügbare ID berechnen und speichern eine neue Instanz der Anfrage mit den übergebenen Daten wiederum in der Tabelle. Die Implementierung für die redeem Aktion funktioniert analog.

Definition der Schnittstelle – ABI

Zusätzlich zum WebAssembly Code besteht der Smart-Contract noch aus einer Definition, die die Struktur und die Interaktion mit dem Smart-Contract beschreibt. Diese wird in Form einer ABI-Datei, wie sie im WebAssembly-Umfeld üblich ist, beschrieben. Bei der Entwicklung in C++ wird diese automatisch generiert. Im Rust SDK fehlt diese Funktionalität zum momentanen Stand allerdings noch.

Die ABI beschreibt die verschiedenen Typen und Aktionen des Smart-Contracts. Sie kann auch manuell geschrieben werden. Weitere Informationen findet man in der EOSIO Entwicklerdokumentation. ⁵

Die ABI für unseren Smart-Contract sieht folgendermaßen aus:

{ "version": "eosio::abi/1.0", "types": [], "structs": [ { "name": "buy", "base": "", "fields": [ { "name": "buyer", "type": "name" }, { "name": "seller", "type": "name" }, { "name": "duration", "type": "uint64" } ] }, { "name": "redeem", "base": "", "fields": [ { "name": "id", "type": "uint64" } ] }, { "name": "runtime", "base": "", "fields": [ { "name": "id", "type": "uint64" }, { "name": "buyer", "type": "name" }, { "name": "seller", "type": "name" }, { "name": "duration", "type": "uint64" }, { "name": "redeemed", "type": "bool" } ] } ], "actions": [ { "name": "buy", "type": "buy", "ricardian_contract": "" }, { "name": "redeem", "type": "redeem", "ricardian_contract": "" } ], "tables": [ { "name": "runtime", "type": "runtime", "index_type": "i64", "key_names": ["id", "buyer", "seller"], "key_types": ["uint64", "name", "name"] } ], "ricardian_clauses": [], "abi_extensions": [] }

Genauere Informationen zur API, zur Smart-Contract Entwicklung und zum Kompilieren findet Ihr hier:

Aufsetzen eines EOSIO Blockchain Netzwerks

EOSIO findet nicht nur beim EOS-Netzwerk Einsatz. Man kann ein zweites offizielles Test-Netzwerk zum Testen der Smart-Contracts nutzen oder sich auch ein eigenes privates Netzwerk aufbauen. Das EOS-Netzwerk ist öffentlich zugänglich und somit sind auch alle gespeicherten Daten frei einsehbar. In unserem Use-Case wollen wir die vertraulichen Abrechnungsdaten allerdings nicht öffentlich preisgeben und bauen uns daher im Folgenden ein abgeschottetes Netzwerk auf.

In EOSIO kann man grundsätzlich die Knoten in unterschiedliche Klassen einstufen.

Es gibt Light-Nodes, also Knoten, die sich nur mit anderen Knoten verbinden, aber keine Daten selbst speichern.
Die Full-Nodes speichern zwar die Blockchain an sich, werden aber keine Blöcke selber produzieren.
Und dann gibt es noch die Block-Producer. Das sind die Knoten im Netzwerk, die dazu ausgewählt wurden, die Blöcke zu produzieren.

Exemplarisch werden wir zwei Knoten aufsetzen und beide als Block-Producer konfigurieren. Der erste Knoten wird vom Hersteller XITASO1 und der zweite vom Hersteller XITASO2 betrieben. Aus Gründen der Vereinfachung werden beide Knoten auf einer virtuellen Maschine mit Ubuntu 18.04 laufen.

Zuerst installieren wird die benötigten Binär-Dateien von EOSIO, welche für die gängigsten Betriebssysteme erhältlich sind. ⁶

EOSIO Development Lifecycle
Quelle: https://developers.eos.io/welcome/latest/introduction-to-eosio/platform_and_toolchain

Es werden drei verschiedene Programme installiert.

keosd – ein Daemon der ein Wallet, also den Key-Store, kontrolliert.
nodeos – die eigentliche Software für die Blockchain-Netzwerk-Knoten.
cleos – die CLI, mit der man die Knoten ansprechen kann und auf das Wallet zugreifen kann.

Zu Beginn starten wir unseren Daemon mit keosd &, da sowohl die Knoten als auch cleos Zugriff auf das Wallet benötigen, und erstellen ein Wallet mit cleos wallet create --to-console. Das Wallet muss zuerst mit cleos wallet open und anschließend mit cleos wallet unlock entsperrt werden.

Unser erster Block Producer gehört zum Account eosio. Dies ist der Standard-Account, welcher immer existiert. eosio signiert die Blöcke mit einem Standard-Key. Dieser wird außerdem benötigt, um Aktionen mit dem Account zu autorisieren. Dieser ist zu Beginn immer gleich, dient nur zu Entwicklungszwecken und sollte schnellstmöglich ersetzt werden! Wir müssen diesen aber zuerst einmal importieren:

$ cleos wallet import 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3

Anschließend können wir den Knoten mit folgendem Befehl starten.

$ nodeos -e -p eosio \ --data-dir ~/.local/share/eosio/eosio \ --config-dir ~/.local/share/eosio/eosio \ --plugin eosio::producer_plugin \ --plugin eosio::producer_api_plugin \ --plugin eosio::chain_api_plugin \ --plugin eosio::http_plugin \ --plugin eosio::history_plugin \ --plugin eosio::history_api_plugin \ --filter-on="*" \ --access-control-allow-origin='*' \ --contracts-console \ --http-validate-host=false \ --verbose-http-errors \ --disable-replay-opts >> eosio.log 2>&1 &

Wir spezifizieren zusätzlich, dass alle Daten im .local/share/eosio/eosio-Ordner gespeichert werden. Die --data-dir und --config-dir Parameter sind optional, sollten bei einem Multi-Node-Netzwerk aber angegeben werden, sonst benutzen alle Knoten den selben Speicherort. Zusätzlich starten wir den Knoten mit einer Hand voll Plugins, die entweder zur Block-Produktion oder für die Kommunikation zwischen cleos und nodeos nötig sind. Weitere Informationen zur Handhabung von nodeos kann man hier finden:

https://developers.eos.io/manuals/eos/latest/nodeos/index

Das Account-System in EOSIO ist baumartig aufgebaut. Jeder Account kann nur von einem anderen Account aus erstellt werden und ist diesem dann untergliedert. Für unseren zweiten Block Producer benötigen wir also einen zweiten Account. Dazu erstellen wir uns zuerst ein neues Schlüssel-Paar bestehend aus einem Public- und einem Private-Key.

$ cleos wallet create_key

Dieser Befehl gibt den öffentlichen Teil des Schlüssels auf der Konsole aus. Diesen werden wir unserem zweiten Account inita zuordnen.

$ cleos create account eosio inita <PublicKey>

Wie bereits erwähnt, ist das Smart-Contract-System sehr modular aufgebaut. So ist die Funktionalität zur Festsetzung der aktiven Block-Producer in einem niedrigen System-Smart-Contract implementiert. Um diesen zu installieren, müssen wir diesen herunterladen und kompilieren.

$ git clone https://github.com/EOSIO/eosio.contracts --branch v1.7.0 --single-branch $ wget https://github.com/EOSIO/eosio.cdt/releases/download/v1.6.3/eosio.cdt_1.6.3-1-ubuntu-18.04_amd64.deb $ sudo apt install ./eosio.cdt_1.6.3-1_amd64.deb

Diese Befehle klonen das open-source Projekt der System-Smart-Contracts von EOSIO und installieren das Development SDK für C++ Smart-Contracts.

Zum Kompilieren wird neben den build-essential auch cmake benötigt.

$ sudo apt install build-essential cmake -y

Nach der erfolgreichen Installation kompilieren wir die Smart-Contract-Projekte.

$ cd /eosio.contracts/ $ rm -fr build $ mkdir build $ cd build $ cmake .. $ make -j$( nproc ) $ cd ..

Die Installation von System-Smart-Contracts muss mit folgendem Befehl freigeschaltet werden. In der Version 2.0 geht das mit folgendem API-Aufruf.

curl -X POST http://127.0.0.1:8888/v1/producer/schedule_protocol_feature_activations -d '{"protocol_features_to_activate": ["

Anschließend können wir den verantwortlichen Smart-Contract eosio.bios installieren.

$ cleos set contract eosio /build/contracts/eosio.bios

Nun spezifizieren wir unsere Block-Producer in einer schedule.json-Datei. Dazu benötigen wir allerdings noch zwei neue Schlüssel-Paare, die als Signierungs-Schlüssel für die Blöcke dienen werden.

$ cleos wallet create_key # output = <PublicKeyEOSIO> $ cleos wallet create_key # output = <PublicKeyINITA>

Dann beschreiben wir unseren aktiven Block-Producer

{ "schedule": [ { "producer_name": "eosio", "block_signing_key": "<PublicKeyEOSIO>" },{ "producer_name": "inita", "block_signing_key": "<PublicKeyINITA>" } ] }

Diese Schedule senden wir dann mithilfe des installierten Smart-Contracts an die Blockchain.

$ cleos push action eosio setprods "<path-to-json>/schedule.json" -p eosio@active

Somit haben wir zwei aktive Block-Producer bestimmt, die jeweils mit unterschiedlichen Schlüsseln die Blöcke signieren. Anschließend starten wir unseren zweiten Knoten inita, damit dieser die bisherige Blockchain-Historie von eosio kopieren kann. Dazu benötigen wir auch noch den privaten Anteil des eben erstellten Schlüssel-Paars. Dazu lassen wir die im Wallet gespeicherten Schlüssel anzeigen.

$ cleos wallet private_keys

$ nodeos -e -p inita \ --data-dir ~/.local/share/eosio/inita \ --config-dir ~/.local/share/eosio/inita \ --http-server-address 0.0.0.0:8889 \ --p2p-listen-endpoint 0.0.0.0:9877 \ --p2p-peer-address 127.0.0.1:9876 \ --plugin eosio::producer_plugin \ --plugin eosio::net_api_plugin \ --plugin eosio::chain_api_plugin \ --signature-provider <PublicKeyINITA>=KEY:<PrivateKeyINITA> \ >> inita.log 2>&1 &

Dabei starten wir diesen zweiten Knoten nur mit Plugins, die wir benötigen, und definieren andere Ports für die eigenen Endpunkte, da die standardmäßigen bereits vom ersten Knoten belegt sind.

Der Knoten eosio hat seinen zugewiesenen Schlüssel allerdings noch nicht, weswegen wir diesen neu starten müssen.

$ ps $ kill $ nodeos -e -p eosio \ --data-dir ~/.local/share/eosio/eosio \ --config-dir ~/.local/share/eosio/eosio \ --plugin eosio::producer_plugin \ --plugin eosio::producer_api_plugin \ --plugin eosio::chain_api_plugin \ --plugin eosio::http_plugin \ --plugin eosio::history_plugin \ --plugin eosio::history_api_plugin \ --filter-on="*" \ --access-control-allow-origin='*' \ --contracts-console \ --http-validate-host=false \ --verbose-http-errors \ --disable-replay-opts \ --signature-provider <PublicKeyEOSIO>=KEY:<PrivateKeyEOSIO> \ >> eosio.log 2>&1 &

Damit haben wir nun ein funktionierendes Multi-Node-Network, auf dem wir unseren selbst gebauten Smart-Contract installieren können. Diesen wollen wir auch einem eigenen Account zuweisen. Außerdem benötigen wir mindestens zwei Test-Accounts, um unseren Use-Case zu testen.

Dazu erstellen wir wieder drei neue Schlüssel-Paare. Für jeden Account eines.

$ cleos wallet create_key # 3x

Danach erstellen wir die neuen Accounts und werden den Smart-Contract auf dem Account iot installieren.

$ cleos create account eosio iot <PublicKeyIOT> $ cleos create account iot testbuyer <PublicKeyBuyer> $ cleos create account iot testseller <PublicKeySeller>

Anschließen installieren wir unseren Smart-Contract. Dieser sollte natürlich bereits zu WebAssembly kompiliert worden sein.

$ cleos set abi iot <path-to-smart-contract>/smartcontract.abi $ cleos set code iot <path-to-smart-contracts-wasm>/smartcontract.wasm

Damit haben wir eine Transaktion mit dem semantischen Kontrakt und dem zugehörigen Code ins Blockchain-Netzwerk gesendet und dort gespeichert.

Zu den Account-Schlüsseln

EOSIO untergliedert die Schlüssel-Paare der Accounts. Wir haben allen Accounts einen sogenannte Owner-Schlüssel zugeteilt. Allerdings kann und sollte man diesem noch einen Active-Schlüssel untergliedern. Alle Interaktionen und Transaktionen sollten mit diesem ausgeführt werden, denn falls dieser gestohlen wird oder abhanden kommt, kann er mittels des Owner-Schlüssel ersetzt werden. Der Owner-Schlüssel kann ohne Weiteres nicht geändert werden.

Die Verbindung zum Netzwerk

Um unsere Anwendung (DAPP) zu testen, benötigen wir einen Client, der mit dem erstellten System interagiert. Dazu stellt EOSIO einen offiziellen Node-Client eos.js zur Verfügung, welcher mit npm installiert werden kann.

Bevor wir mit diesem Client eine Transaktion ans Netzwerk schicken können, benötigen wir den privaten Schlüssel eines Accounts, der diese dann signiert. Um einen Service zu beanspruchen, verwenden wir den testbuyer Account. Um die Keys des Accounts ausfindig zu machen, können wir mit cleos das Netzwerk und anschließen unser Wallet abfragen.

$ cleos get account testbuyer # -> Owner Pulic Key $ cleos wallet private_keys # Eintrag mit Public Key finden

Um per eos.js mit dem Netzwerk eine Verbindung aufzubauen, stellt der Client zwei Klassen zur Verfügung. JsonRpc baut die rpc-Verbindung zum Knoten auf und Api verwendet wiederum JsonRPC und kümmert sich um die Kodierung und weitere Logik. Zusätzlich müssen wir den Private-Key in einer SignatureProvider-Instanz der Api übergeben. Für den Prototyp verwenden wir dafür den JsSignatureProvider , welcher allerdings nur für Entwicklungszwecke gedacht ist.

import { JsSignatureProvider } from 'eosjs/dist/eosjs-jssig'; import { JsonRpc, Api, RpcError } from 'eosjs'; import fetch = require('node-fetch'); import { TextEncoder, TextDecoder } from 'util'; const hostUrl = 'http://127.0.0.1:8888'; const privateKey = ''; const signatureProvider = new JsSignatureProvider([privateKey]); const rpc = new JsonRpc(hostUrl, { fetch } ); const api = new Api({rpc, signatureProvider, textDecoder: new TextDecoder(), textEncoder: new TextEncoder()}); function buyService(amount) { const payload = { account: 'iot', name: 'buy', authorization: [{ actor: 'testbuyer', permission: 'active' }], data: { buyer: 'testbuyer', seller: 'testseller', duration: amount, } }; const options = { blocksBehind: 3, expireSeconds: 30 }; try { return await api.transact({actions: [payload]}, options); } catch(err) { console.log("Could not transact: " + err); if (err instanceof RpcError) console.log(JSON.stringify(err.json, null, 2)); } }

So könnte die Funktion für eine Kaufanfrage eines Services auf der Client-Seite aussehen. eos.js bietet zusätzlich die Möglichkeit, die gespeicherten Daten und Information über Blöcke abzufragen. Diese Funktionalitäten werden mithilfe von nodeos-Plugins auf den Nodes implementiert.

Zusammenfassung

Wir haben uns zum einen damit befasst, wie man ein Multi-Node-Netzwerk mit EOSIO aufbaut und wie man dort verschiedene Smart-Contracts installiert sowie die notwendigen Accounts mit Permissions einrichtet. Außerdem haben wir einen kurzen Blick auf die Integration von Clients mit eos.js geworfen. Mit unserem entwickelten Prototyp haben wir die potenziellen Möglichkeiten von EOSIO angekratzt. EOSIO bietet mit seiner sehr guten Dokumentation einen sanften Einstieg in die Entwicklung mit der Blockchain-Technologie.

In unserem Use-Case haben wir dargestellt, wie eine digitale interoperable Plattform im industriellen Umfeld aussehen könnte, um damit neue Geschäftsmodelle wie Pay-Per-Use umzusetzen. Neuartige Blockchain-Technologien wie EOSIO ermöglichen eine einfache und schnelle Umsetzung einer sicheren Prozessabwicklung und bieten damit ein enormes Potenzial für die Industrie.