1.0 Einführung und Ziele
Star Notary Service erlaubt es, Sterne mit Koordinaten in der Ethereum Blockchain zu speichern. Diese Applikation ist eine Demoanwendung, welche die Funktionsweise einer DApp demonstriert. Es wird die Funktionsweise von Solidity und Interaktion mit Javascript vorgestellt.
1.1 Aufgabenstellung
Die Anwendung implementiert den Ethereum ERC-721 Token Standard als Solidity Smart Contract. Der Webfrontend nutzt Javascript. Die Anwendung speichert den Start Name, eine Beschreibung und die Koordinaten (RA Rektaszension, mag Absolutwert, cen Zentaur).
1.2 Qualitätsziele
Die Applikation soll als Demoanwendung lauffähig sein.
1.3 Stakeholder
| Rolle | Erwartungshaltung |
|---|---|
| Leser | Interesse an Software Architektur Dokumentation, Smart Contract. |
| Stefan Zils | Wissensaufbau, Erfahrungen für produktiven Einsatz. |
2.0 Randbedingungen
- Programmiersprachen und Bibliotheken:
- Smart Contracts in Solidity.
- Javascript für die Entwicklung des Webfrontends.
- Web3.js als Library zur Verbindung mit dem Ethereum-Netzwerk.
- Laufzeitumgebungen sind:
- Ethereum Virtual Machine (EVM).
- Lokale EVM Ganache (Entwicklung).
- OpenZepplin zur Generierung der ERC Token Standards. (ERC bedeutet Ethereum Request for Comments).
- Nodejs zum Betrieb der lokalen Tests und des Deployments (Entwicklung).
- MetaMask für die Verbindung zwischen Webfrontend und dem Ethereum Netzwerk.
- Die Entwicklung der Software erfolgt mit den freien Entwicklungswerkzeugen Microsoft Visual Studio Code und die Truffel Suite (Truffle, Ganache, https://truffleframework.com).
- Dokumentationswerkzeuge sind Sparx Enterprise Architekt und Microsoft Word.
- Arch42 wird als Dokumentationsstandard verwendet.
3.0 Kontextabgrenzung
3.1 Fachlicher Kontext
Abbildung 3–1 Fachlicher Kontext Star Notary
Abbildung 3–1 zeigt den fachlichen Kontext, dieser beschreibt zwei Rollen. Einen Stern Entdecker, welcher neue Sterne im System erfasst und einen Stern Notary Benutzer, welcher Sterne im System sucht und Eigentumsrechte erwerben kann.
3.2 Technischer Kontext
Abbildung 3–2 Technischer Kontext Star Notary
Abbildung 3–2 beschreibt den technischen Kontext. Ein Benutzer greift mittels Webbrowser auf dem Webserver zu. Der Webserver kommuniziert mit dem Ethereum-Netzwerk.
4 Lösungsstrategie / Querschnittliche Konzepte
Star Notary Service ist eine DApp, welche es einem Nutzer erlaubt Sterne in der Ethereum Blockchain zu erfassen und Sterne zu kaufen. Die Implementierung der App erfolgt nach dem ERC-721 Token Standard der Ethereum Plattform.
5 Bausteinsicht
5.1 Whitebox Gesamtsystem
Abbildung 5–1 Whitebox Gesamtsystem, Star Notary
Abbildung 5–1 zeigt die wichtigsten Komponenten die miteinander agieren. Diese sind die Ethereum Virtual Machine (EVM), der Webserver und der Webbrowser.
5.2 Blockbox Gesamtsystem
Abbildung 5–2 Blockbox Gesamtansicht, Star Notary
Abbildung 5–2 zeigt die Kommunikation der einzelnen Komponenten im Detail. Der Smart Contract StarNotary wird in der EVM betrieben. Im Webserver wird das Webfrontend in Form der Datei index.html zur Verfügung gestellt. Die Kommunikation im Webserver erfolgt via der Javascript-Bibliothek web3.js und dem Plugin MetaMask zum Smart Contract. Ergänzend: MetaMask wird zusätzlich im Webbrowser betrieben und fungiert dort als Ethereum-Waltet
6.0 Verteilungssicht
Abbildung 6–1 zeigt die Verteilungen einer DApp auf die einzelnen Laufzeitumgebungen und Server.
7.0 Entwurfsentscheidungen
Die Entscheidung für die genannten Programmiersprachen, Umgebungen und Tools erfolgt zur Evaluation der Ethereum-Plattform und dem DApp Konzept.
8.0 Risiken und technische Schulden
Zurzeit liegen keine genauen Betriebsdaten der Ethereum-Plattform im produktiven Einsatz vor. Die Skalierung kann nur angenommen werden. Rückschlüsse auf die Betriebskosten sind nur begrenzt möglich. Es gibt keine Erfahrungen bzgl. Laufzeitverhalten und Angriffe auf Smart Contracts.
Vyper setzt sich als Programmiersprache gegenüber Solidity durch und überzeugt mit neueren Konzepten. Hieraus resultieren Risiken wie spätere Migrationskosten und Verlust des erlernten und erarbeiteten Wissens.
Eine DApp ist nach dem Cynefin-Framework als komplex einzuordnen. Die EVM kapselt zwar viele Probleme, es fehlen Erfahrungswerte bzgl. der Speicherung von Massendaten innerhalb der Ethereum Blockchain. Jeder Smart Contract kann Daten ausschließlich in Form einer Zuordnung (Mapping) eines Schlüssels (Key) speichern. Dies ist ein großer Unterschied zu bekannten Datenbanken (z. B. Relationale Datenbanken). Lastgrenzen eines Smart Contracts sind nicht bekannt. Es ist anzunehmen, dass alle Daten im jeweiligen lokalen Speicher der EVM vorgehalten werden. Daher sind Speichermodelle weiter zu evaluieren. Bei geschlossenen DLT-Systemen können die Daten in anderen zentralen Systemen gespeichert werden (Bspw. Verknüpfung mit ERP-Systemen, Relationalen Datenbank etc.). Bei öffentlichen DLT-Systemen ist eine Auslagerung von verschlüsselten Daten auf den externen Speicher wie das Interplanetary Filesystem (IPFS) denkbar.
Die Kommunikation zwischen der Internetseite mit der Bibliothek web3.js und MetaMask und Smart Contract benötigt einiges an Konfigurationserfahrung. Mit dem Google Chrome Browser lief das System am stabilsten. Der Umgang mit Smart Contract benötigt Erfahrung und Sorgfalt. Jede neue Version eines Smart Contract enthält eine eigene Adresse. Softwareentwickler sollten Ethereum sowie die entsprechenden Entwicklungswerkzeuge verstehen und beherrschen können. Im produktiven Einsatz ist es empfehlenswert Standardkonfigurationen auszuarbeiten.
9.0 Copyright arc42 Template
Arc42, das Template zur Dokumentation von Software- und Systemarchitekturen. Erstellt von Dr. Gernot Starke, Dr. Peter Hruschka und Mitwirkenden. Template Revision: 7.0 DE (asciidoc-based), January 2017
© We acknowledge that this document uses material from the arc42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.
