Konzeption eines transparenten und manipulationssicheren Monitorings für Service Level Agreements in der Blockchain

Abstract

Ein Thema der aktuellen Blockchain-Forschung sind inzwischen auch Smart Contracts (digitale Verträge), die in einer Blockchain abgelegt werden (nach BODO, GERVAIS und QUINTAIS 2018). Dieser Artikel untersucht, inwiefern es möglich ist, das Monitoring (die Überwachung) eines Service Level Agreements (in Form eines Smart Contracts) durch die Blockchain-Technologie für Servicenehmer und Serviceprovider gleichermaßen transparent und manipulationssicher zu gestalten. Dazu wird das bestehende Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) erweitert.

1. Einleitung und Forschungsfrage

Neue Geschäftsmodelle ändern die Art und Weise, wie Unternehmen Gewinne erwirtschaften. Inzwischen beinhalten Geschäftsmodelle auch E-Services. Der Begriff „E-Service“ bezeichnet „ein Dienstleistungskonzept für das Bündeln und Bereitstellen von Leistungen über das Internet“ (BOLLHÖFER 2017, S. 40). Dabei erfolgen Kommunikation, Information und Transaktionen vermehrt über technische Systeme, die inzwischen auch autark entscheiden und interagieren (nach BOLLHÖFER 2017, S. 40). Die qualitativen Anforderungen an einen E-Service werden in einem „Service Level Agreement“ (SLA) definiert. Nach SCHOLDERER (2016, S. 11 f.) ist ein SLA eine schriftliche vertragliche Vereinbarung (Servicevertrag) zwischen einem Serviceprovider (SP) und einem Servicenehmer (SN). Bisher ist es jedoch noch immer notwendig, dass sich SP und SN zur inhaltlichen Abstimmung von SLAs persönlich treffen (nach SCHOLDERER 2016, S. 13). Nach SCHEID und STILLER (2018) verursachen Abschluss und Monitoring von SLAs einen Aufwand in den Unternehmen. Nach SCHOLDERER (2016, S. 53) und in Anlehnung an BERGER (2005, S. 171 ff.) wäre jedoch ein Lebenszyklus für SLAs ideal (vgl. Kapitel 4.1), der diese dynamisch auf Anforderungsänderungen kontrolliert und anpasst. Hier besteht ein Zielkonflikt.

Eine Lösung könnte durch dynamische SLAs in Form von Smart Contracts (digitalen Verträgen) in der Blockchain erfolgen. Die Unternehmensberatung PricewaterhouseCoopers (PwC) und das Marktforschungsunternehmen Gartner zählten im Jahr 2017 die Blockchain zu den Schlüsseltechnologien und Megatrends (nach WOODSIDE, AUGUSTINE und GIBERSON 2017, S. 67). Das Monitoring von SLAs (in Form von Smart Contracts in der Blockchain) beschreiben NEIDHARDT, KÖHLER und NÜTTGENS (2018) auf konzeptioneller Ebene. Die Aspekte „Transparenz“ (Nachvollziehbarkeit) und „Manipulationssicherheit“ (Schutz vor einer Vorteilsverschaffung) werden jedoch nicht berücksichtigt.

Unter der noch zu prüfenden Voraussetzung, dass sich das Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) für eine Erweiterung eignet (vgl. Kapitel 4.3), resultiert die folgende Forschungsfrage (F):

Abbildung in dieser Leseprobe nicht enthalten

2. Methodik

Nach der Definition der Forschungsfrage wird eine adäquate wissenschaftliche Vorgehensweise (Methodik) ausgewählt und beschrieben. Zunächst wird die Eignung des Konzepts von NEIDHARDT, KÖHLER und NÜTTGENS (2018) geprüft. Die Beantwortung der Forschungsfrage erfordert schließlich dessen Erweiterung. Bei der Entwicklung einer Blockchain-Anwendung verwenden KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018, S. 182) erfolgreich einen mehrphasigen Entwicklungsprozess. In Anlehnung hieran wird deshalb die Bearbeitung der Forschungsfrage in zwei Phasen unterteilt:

1. Phase: Analyse (Identifikation der Problembereiche und Anforderungen) und
2. Phase: Konzeption (Erfüllung der Anforderungen in einem neuen Konzept).

KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018, S. 182 und S. 186) identifizieren bei der Analyse (1. Phase) die Anforderungen an das neue System. Die Autoren beschreiben jedoch die Vorgehensweise nicht im Detail. Deshalb wird ein methodischer Ansatz gewählt, der sich an den von VERSTEEGEN (2000, S. 91 ff.) beschriebenen Anforderungsworkflow aus dem „Rational Unified Process“ (RUP) anlehnt. Dabei wird zunächst das Problemfeld analysiert (nach VERSTEEGEN 2000, S. 92). Bei der Analyse wird das Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) in einzelne Bestandteile zerlegt. Diese werden hinsichtlich Transparenz und Manipulationssicherheit untersucht. Hierbei werden die änderungsrelevanten Problembereiche identifiziert und im Anschluss in Anforderungen überführt. Die Anforderungen beschreiben, wie sich das neue System verhält (nach VERSTEEGEN 2000, S. 85). Nach VERSTEEGEN (2000, S. 85 f.) ist die schriftliche Formulierungsweise der Anforderungen für die Qualität des neuen Systems von Bedeutung. Zur Vermeidung sprachlicher Missverständnisse werden die Anforderungen gemäß einer Satzschablone als Textbausteine formuliert (nach POHL und RUPP 2015, S. 57 ff.).

Die folgende Abbildung 1 zeigt die Satzschablone:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Einfache Satzschablone (nach POHL und RUPP 2015, S. 57 ff.)

Die Beschreibung einer einzelnen Anforderung wird aus je einem Wort bzw. Ausdruck der Bereiche (1) bis (3) zusammengesetzt. Aus Bereich (2) ist ein „Modalverb“ zu wählen, das die Verbindlichkeit der Anforderung ausdrückt (nach POHL und RUPP 2015, S. 58). Aus Bereich (3) wird ein „Prozesswort“ gewählt, das eine Funktion (z. B. „Speicherung“) bestimmt. Nach POHL und RUPP (2015, S. 58 f.) wird in Bereich (3) nach selbständiger Systemaktivität (3a), Benutzerinteraktion (3b) und Schnittstellenanforderung (3c) unterschieden. Ein Beispiel: „Das System (1) muss (2) dem Serviceprovider die Möglichkeit zur Speicherung bieten (3b)“.

Nach VERSTEEGEN (2000, S. 90) lassen sich die Anforderungen in „nichtfunktionale Anforderungen“ und „funktionale Anforderungen“ unterteilen. Nichtfunktionale Anforderungen beschreiben z. B. Wartbarkeit, Performance usw. Bei der Konzeption des neuen Systems wird bewusst auf die Beschreibung nichtfunktionaler Anforderungen verzichtet, da diese zunächst als unwesentlich in Bezug auf die Forschungsfrage erachtet werden. Funktionale Anforderungen beschreiben ausschließlich die zu erwartende Funktionalität des neuen Systems (nach VERSTEEGEN 2000, S. 90 f.). Nach KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018, S. 186) ist das Ziel der Analyse eine möglichst vollständige Zusammenstellung der neuen funktionalen Anforderungen. Aus Komplexitätsgründen wird das Monitoring-Objekt jedoch bei der Analyse abstrahiert. Bei der Identifikation der funktionalen Anforderungen wird davon ausgegangen, dass ein E-Service überwacht wird, der sich auf einem Web-Server im Internet befindet. Die Komplexität wird somit auf die Verfügbarkeit einer Web-Anwendung reduziert. Dies bedeutet eine Abweichung von realen Gegebenheiten, da sich SLAs im Allgemeinen nicht nur auf Verfügbarkeiten von Web-Anwendungen beschränken. Diese Einschränkung ist jedoch auch bei SCHEID und STILLER (2018) sowie NEIDHARDT, KÖHLER und NÜTTGENS (2018) vorhanden und ist deshalb methodisch vertretbar.

Die identifizierten funktionalen Anforderungen bilden die Grundlage für die neue Konzeption (2. Phase). Die Verwendung von Entwurfsmustern ist jedoch nicht möglich, da für Blockchains derzeit in diesem Bereich noch Forschungsbedarf besteht. KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018, S. 182 und S. 186 ff.) beschreiben auf Grundlage der Anforderungen die Hauptkomponenten des neuen Systems. Diese Vorgehensweise ist konform mit der aktuellen Empfehlung von ROCHA und DUCASSE (2018) für Blockchain-Konzeptionen. Aufgrund von Konformität und Detaillierungsgrad wird die Vorgehensweise von ROCHA und DUCASSE (2018) für die neue Konzeption ausgewählt. ROCHA und DUCASSE (2018, S. 53 ff.) betrachten die folgenden Modellierungsstandards als geeignet:

1. Business Process Model and Notation (BPMN)
2. Entity Relationship Model (ERM)
3. Unified Modeling Language (UML)

Im Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) wird die BPMN verwendet. Die „BPMN ist eine Modellierungssprache mit dem Anspruch, sowohl organisatorische wie auch technische Modelle flexibel und in einer grafischen Notation zu erstellen“ (BOLLHÖFER 2017, S. 62). Aufgrund der Anlehnung an KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018) wird jedoch bei der konzeptionellen Erweiterung die UML verwendet. Aus der UML wird das Komponentendiagramm (engl. „Component Diagram“) ausgewählt, da es sich besonders für die Spezifikation von Softwarearchitekturen eignet (nach KECHER, SALVANOS und HOFFMANN-ELBERN 2018, S. 155). Nach KECHER, SALVANOS und HOFFMANN-ELBERN (2018, S. 161) ist die Expressivität des Komponentendiagramms auf Komponenten bzw. Teilsysteme und Schnittstellen begrenzt. Bei der Konzeption bedeutet dies jedoch keine methodische Schwachstelle, da die komplexe Systemdarstellung dadurch hinreichend an Übersicht gewinnt. Es kommt zu keinem Informationsverlust. Das Komponentendiagramm wird erweiternd eingesetzt, nicht ersetzend. Nach KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018, S. 186) ist das Ziel der Konzeption eine möglichst vollständige Berücksichtigung der Anforderungen.

Gemäß der soeben aufgezeigten Methodik wird im Weiteren vorgegangen.

3. Vorgehensweise

Die Vorgehensweise richtet sich nach der im vorherigen Kapitel beschriebenen Methodik. Zunächst wird in Kapitel 4 der aktuelle Stand beschrieben. Die Darstellung des aktuellen Stands erfolgt generalisierend. Bei der Beschreibung wird aus Umfangsgründen lediglich auf aktuelle Forschungsartikel und Fachliteratur verwiesen. Es wird auch geprüft, ob das Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) dem aktuellen Stand entspricht und für eine Erweiterung geeignet ist (vgl. Kapitel 4.3).

In Kapitel 5 wird die Analyse (1. Phase) beschrieben. Das Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) wird dabei zergliedert. Die einzelnen Bestandteile werden nach Problembereichen hinsichtlich Transparenz und Manipulationssicherheit des Monitorings untersucht. Die resultierenden Problembereiche liefern Hinweise für Verbesserungs-möglichkeiten. Aus den identifizierten Problembereichen werden die neuen funktionalen Anforderungen abgeleitet.

In Kapitel 6 wird die Konzeption (2. Phase) beschrieben. Die in Kapitel 5 erarbeiteten Anforderungen werden bei der Konzeption berücksichtigt und in das bestehende Konzept von NEIDHARDT, KÖHLER und NÜTTGENS (2018) integriert. Das Ergebnis ist ein neues Konzept in Form eines Komponentendiagramms in der UML.

Zum Schluss werden in Kapitel 7 die Erkenntnisse zusammengefasst. Entsprechend der soeben aufgezeigten Vorgehensweise wird nun mit der Beschreibung des aktuellen Stands begonnen.

4. Aktueller Stand

Aktuelle Forschungsartikel haben sich bisher nur ansatzweise mit dem Monitoring von SLAs (in Form von Smart Contracts in der Blockchain) beschäftigt. Die Inhalte der letzten relevanten Artikel werden im Folgenden rekapituliert.

Im April 2018 wurde von SCHEID und STILLER ein Artikel veröffentlicht, der die technische Umsetzung eines SLAs durch einen Smart Contract (vgl. Kapitel 4.2.3) in der Blockchain beschreibt. Durch die Verwendung eines Smart Contracts werden SLAs dynamischer (vgl. Kapitel 4.1). Der Artikel behandelt jedoch das Monitoring von SLAs (Smart Contracts) nur marginal.

Eine Vertiefung des Monitoring-Aspekts erfolgt durch NEIDHARDT, KÖHLER und NÜTTGENS (2018). Diese beschreiben die Erweiterung von SLAs (Smart Contracts) um eine externe Schnittstelle („Oraclize“), die Daten aus einem Monitoring-System (z. B. Nagios) einliest. Es wird jedoch auch in diesem Konzept nicht aufgezeigt, wie SLAs (Smart Contracts) transparent und manipulationssicher überwacht werden können. Tatsächlich sind Transparenz und Manipulationssicherheit für SP und SN (vgl. Kapitel 1) gleichermaßen von Bedeutung, da SLAs oftmals Pönalen (Strafzahlungen) beinhalten. Derzeit existiert kein Forschungsartikel, der ein transparentes und manipulationssicheres Monitoring von SLAs (Smart Contracts) beschreibt. Erstmalig sollen durch die Klärung der Forschungsfrage diese Aspekte konzeptuell berücksichtigt werden.

Für ein besseres Verständnis des Konzepts von NEIDHARDT, KÖHLER und NÜTTGENS (2018) und der darauffolgenden konzeptionellen Erweiterung werden in den folgenden Kapiteln die aktuellen Methoden und Technologien ausführlicher beschrieben. Zunächst wird näher auf aktuelle Entwicklungen im Management von SLAs eingegangen.

4.1 Service Level Management (SLM)

SLAs werden durch das „Service Level Management“ (SLM) gesteuert (nach SCHOLDERER 2016, S. 49). Nach SCHOLDERER (2016, S. 52 ff.) ist das SLM ein mehrphasiger, kontinuierlicher Prozess, der die SLAs optimiert (Lebenszyklus). Nach MENDES und DA SILVA (2016, S. 69) sind veränderbare bzw. dynamische SLAs ideal für Unternehmen, da diese eine Reaktion auf Gaps (Lücken) in SLAs ermöglichen. Die folgende Abbildung 2 zeigt den Lebenszyklus von SLAs:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Idealisierter Lebenszyklus (nach SCHOLDERER 2016, S. 53 und in Anlehnung an BERGER 2005, S. 171 ff.)

Bei einem SLA befinden sich SP und SN (vgl. Kapitel 1) in unterschiedlichen Unternehmen (nach SCHEID und STILLER 2018). Dies bedeutet einen Aufwand für die beteiligten Unternehmen bei Vertragsabschluss bzw. der Definition des SLAs (1). Die Anforderungen an den IT-Service müssen identifiziert, abgegrenzt und präzise in einem Vertrag beschrieben werden. Im Weiteren werden die aus den Anforderungen abgeleiteten Vertragsinhalte vereinfachend „SLA-Parameter“ genannt. Die SLA-Parameter werden von den aktuellen Standards für IT-Services (z. B. ITIL) jedoch nicht im Detail beschrieben (nach SCHOLDERER 2016, S. 47 ff.). Derzeit existieren verschiedene SLA-Frameworks parallel, die SLAs beschreiben bzw. versuchen diese zu standardisieren. Beispielsweise das „ Web Service Level Agreement“ (WSLA), das speziell auf die Gestaltung von SLAs für Webservices ausgerichtet ist (nach KELLER und LUDWIG 2003). Auch das auf ITIL basierende „SOUSIS-Modell“ beschreibt eine Standardisierung von SLAs speziell für IT-Services (nach SCHOLDERER 2016, S. 84 ff.). Eine umfassende Darstellung der aktuellen, divergierenden SLA-Frameworks ist an dieser Stelle nicht möglich. Im Folgenden werden stattdessen exemplarisch einige SLA-Parameter für einen Webserver aufgezeigt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Beispiel für SLA-Parameter eines Webservers (nach KELLER und LUDWIG 2003 und nach SCHEID und STILLER 2018)

Die SLA-Parameter eines IT-Services werden qualitativ über Soll-Kennzahlen definiert (z. B. die prozentuale Verfügbarkeit, vgl. Tabelle 1). Am Ende der Definitionsphase enthält das SLA die Vereinbarungen zwischen SP und SN (nach SCHOLDERER 2016, S. 53).

Im Anschluss werden organisatorische, personelle und technische Maßnahmen bei SP und SN aus dem SLA abgeleitet und implementiert (2). Beispielsweise durch Veränderungen von Prozessen, Zuständigkeiten und Informationsflüssen oder den Austausch von Geräten. Am Ende der Phase sind die definierten Anforderungen von SP und SN umgesetzt (nach SCHOLDERER 2016, S. 53).

Während der Nutzung (3) wird die Einhaltung des SLAs kontrolliert. Es erfolgt ein kontinuierliches Monitoring des SLAs. Zur Überwachung können Monitoring-Systeme (z. B. Nagios) eingesetzt werden, die beispielsweise die Verfügbarkeit des zu überwachenden Systems regelmäßig erfassen. Bestandteil des Monitorings ist die Ermittlung (a) von Ist-Kennzahlen (Ist-Verfügbarkeit). Abweichungen im SLA ergeben sich aus der Auswertung (b), d. h. dem Soll-Ist-Vergleich der Kennzahlen. Abweichungen müssen protokolliert werden, da sich daraus Pönalen ergeben können. Der SP ergreift bei Abweichungen Maßnahmen zur Steuerung (c) der Servicequalität (nach SCHOLDERER 2016, S. 54).

Durch Veränderungen von Services oder sich ändernde Rahmenbedingungen (z. B. Kosten) können sich auch SLA-Parameter ändern (nach SCHOLDERER 2016, S. 54 f.). Eine regelmäßige Kontrolle (4) der im SLA definierten Parameter ist notwendig.

Zusammenfassend ist aus Abbildung 2 ersichtlich, dass ein dynamisches SLM einen erheblichen Aufwand bedeutet. Zur Verringerung des Aufwands wird das SLM idealerweise durch geeignete Tools unterstützt. In den Unternehmen generieren derartige Tools aus den vorhandenen SLA-Parametern bislang jedoch keinen Mehrwert, wie beispielsweise das Monitoring – obwohl dies möglich wäre. Erstmalig beschreiben NEIDHARDT, KÖHLER und NÜTTGENS (2018), wie durch einen Smart Contract ein Mehrwert erzeugt werden kann. Problematisch bei diesem Ansatz sind jedoch die Aspekte Transparenz und Manipulationssicherheit. Auch NEIDHARDT, KÖHLER und NÜTTGENS (2018) beschreiben nicht, wie ein einerseits dynamischer Smart Contract (SLA) durch ein andererseits statisches Monitoring überwacht wird, das gleichzeitig auch noch transparent und manipulationssicher für SP und SN ist. Eine Lösung des Problems liefert die Blockchain, die gleichzeitig dynamisch und statisch ist.

4.2 Blockchain

Nach YLI-HUUMO, KO, CHOI, u. a. 2016, S. 1) beschäftigen sich nur 20 % der Blockchain-Forschung mit der Konzeption von Blockchain-Anwendungen. BEN AYED und BELHAJJI (2017, S. 1) verwenden für den Begriff „Blockchain” die folgende Definition: „A Blockchain is essentially a dispersed data source of records, or public ledger, of all transactions or digital occasions that have actually been executed and also shared amongst participating parties. Each transaction in the public ledger is verified by the consensus of the majority of participants in the system. Once admitted, details can never, ever be removed.“

Wichtige Eigenschaften bei der Entwicklung von Blockchain-Anwendungen sind somit die Verteilung von Datensätzen und die Unmöglichkeit, Datensätze zu löschen, die in der Blockchain gespeichert wurden. Genau diese Eigenschaften beschränken jedoch auch die konzeptionelle Expressivität.

Eine aktuelle Gesamtübersicht zur Blockchain liefert der Standard NISTIR8202 (2018). Der Herausgeber des Standards ist das „National Institute of Standards and Technology“ (NIST), das eine Bundesbehörde der Vereinigten Staaten ist. Bei NISTIR8202 (2018) handelt es sich somit nicht um einen ISO-Standard oder um eine Norm. Im Folgenden wird der aktuelle Entwicklungsstand der Blockchain (gemäß NISTIR8202) aufgezeigt. Ergänzend zu NISTIR8202 (2018) werden verschiedene Forschungsartikel verwendet, die im Weiteren bei Bedarf explizit angeführt werden.

4.2.1 Struktur

Eine Blockchain besteht aus einzelnen Blöcken. Nach BEN AYED und BELHAJJI (2017, S. 2) ist ein „Block“ ein Bereich bzw. Container, welcher sich aus zwei Teilen zusammensetzt:

1. Der „Block-Header“ enthält Informationen über den Block (Metadaten). Im Block-Header befindet sich der „Timestamp“, der Datum und Uhrzeit des Hinzufügezeitpunktes des Blocks zur Blockchain enthält.
2. Der „Datenbereich“ enthält zusammengehörende Daten bzw. Transaktionen, die dem Block zugeordnet werden.

Die folgende Abbildung 3 zeigt den Aufbau eines Blocks:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Block¹

Der erste Block in einer Blockchain wird Genesis Block genannt. Der „Genesis Block“ ist die existenzielle Grundlage zur Verkettung weiterer Blöcke (n). Für die Verkettung wird eine Hash-Funktion verwendet. Nach BEN AYED und BELHAJJI (2017) wird ein Hash-Algorithmus (z. B. SHA256) auf die Block-Header eines jeden Blocks angewendet. Der Hash-Wert (resultierend aus SHA256) eines jeden Block-Headers wird „Block-Header-Hash“ genannt. Die erzeugten Block-Header-Hashes sind für jeden Block-Header unterschiedlich. Jeder Block-Header in einer Blockchain enthält den „Previous-Block-Header-Hash“, der den Block-Header-Hash des vorherigen Blocks enthält:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Struktur²

Durch die verschiedenen Block-Header-Hashs werden die Blöcke miteinander verkettet. Außerdem wird durch sie die Integrität der verketteten Blöcke sichergestellt. Der Begriff „Integrität“ ist ein Schutzziel der Informationssicherheit und bezieht sich auf die Korrektheit bzw. Unversehrtheit (nach WITT 2009, S. 72 ff.). Manipulationen am Block-Header eines Blocks führen zu einem veränderten Block-Header-Hash, der dann nicht mehr mit dem Previous-Block-Header-Hash des nachfolgenden Blocks identisch ist. ZHAO, FAN und YAN (2016, S. 3) erklären zusammenfassend: „Blockchain technology includes several preventive mechanisms (e.g., distributed consensus and cryptography) to reduce risks”. Die von NEIDHARDT, KÖHLER und NÜTTGENS (2018) verwendete Blockchain reduziert somit Risiken.

4.2.2 Node

Die zuvor beschriebene Struktur einer Blockchain wird in einer Programmiersprache implementiert (Blockchain-Implementierung). Die Implementierung wird anschließend als reale Instanz auf einer physikalischen Maschine gestartet. Der englische Begriff „Node“ (deutsch „Knoten“) bezeichnet solch eine reale Instanz. Mehrere Instanzen werden in einem Peer-To-Peer-Netzwerk durch einen Algorithmus zur Blockreplikation verbunden. Ein Node enthält bei der Replikation entweder eine vollständige Kopie aller Blöcke im Netzwerk („Full-Node“) oder stellt eine Verbindung zu einem Full-Node her, um auf die Blöcke anderer Nodes zugreifen zu können („Lightweight-Node“). Die Art der Replikation richtet sich nach der Konfiguration des Nodes. Nach KARAMITSOS, PAPADAKI und AL BARGHUTHI (2018, S. 180) lassen sich Nodes auch bzgl. der Zugriffsbeschränkung in zwei Typen unterscheiden:

Abbildung in dieser Leseprobe nicht enthalten

4.2.3 Unterschiede des API im Datenbereich

Die Blockchain-Implementierungen (z. B. „Ethereum“ und „Multichain“) unterscheiden sich funktional im „Application Programming Interface“ (API) in den Zugriffsmöglichkeiten auf die Datenbereiche von Blöcken.

Bei der Blockchain-Implementierung Ethereum (Public-Node) können im Datenbereich Transaktionen und Smart Contracts abgelegt werden. Eine „Transaktion“ ist ein Datensatz, der das Eigentum an einer Sache beschreibt und in einem Block gespeichert wird (nach DRESCHER 2017, S. 249). Beispielsweise ist eine Zahlung in der Ethereum-Währung ETH eine Transaktion. Nach DRESCHER (2017, S. 249) ist ein „Smart Contract“ ein Vertrag in Form eines Computerprogramms, das ebenfalls im Datenbereich gespeichert wird. Der zugrundeliegende Quellcode wird in der Programmiersprache „Solidity“ erzeugt, von einem Compiler in einen Bytecode übersetzt und dann in der „Ethereum Virtual Machine“ (EVM), die in jedem Ethereum-Node integriert ist, ausgeführt. Der Smart Contract kann dann durch Transaktionen aktiviert werden. Derjenige der den Ethereum-Node betreibt, wird „Miner“ genannt und bekommt für die Ausführung des Smart Contracts auf dem Node ETH. Das Computerprogramm beinhaltet Regeln, Funktionen und Zustandsvariablen. Die Expressivität von Zustandsbeschreibungen ist dabei auf eine Smart-Contract-interne Sichtweise beschränkt. In Ethereum können jedoch keine beliebigen Daten im Datenbereich abgelegt werden. Dies schränkt die Expressivität des API ein.

[...]

¹ Eigene Darstellung

² Eigene Darstellung