Bachelorarbeit FAKULT AT INFORMATIK - Jan Alexander Welling Die Umsetzbarkeit von Tokensales in der Blockchain - OPUS 4
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
FAKULTÄT INFORMATIK
Bachelorarbeit
Die Umsetzbarkeit von Tokensales in der Blockchain
Jan Alexander Welling
Betreuer: Prof. Dr.-Ing. Johann Uhrmann
In Kooperation mit
xpecto talonec GmbH
ERKLÄRUNG ZUR BACHELORARBEIT
(gemäß § 11, Abs. (4) 3 APO)
Welling, Jan Alexander
Hochschule Landshut
Fakultät Informatik
Hiermit erkläre ich, dass ich die Arbeit selbständig verfasst, noch
nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als
die angegebenen Quellen oder Hilfsmittel benützt, sowie wörtliche
und sinngemäße Zitate als solche gekennzeichnet habe.
.................... ....................................................
(Datum) (Unterschrift des Studierenden)
Zusammenfassung/Abstract Mit der Erfindung der Blockchain eröffnete sich eine neue Sparte in der IT-Welt. Ihre stetige Weiterentwicklung sorgt für immer mehr Anwendungsfälle. So bot sich auch für die xpecto/talonec GmbH der Einstieg in die Technologie. Mit ihrem Anwendungsfall, der Realisierung des Tokensales in der Blockchain, wird sich eine Optimierung des Online- Zeichnungsprozesses erhofft, indem das traditionelle Bankdepot durch Smart Contracts in der Blockchain ersetzt wird. Damit wurde sich das Ziel gesetzt die Gebühren und den Zeit- aufwand für Emittenten und Anleger zu verringern, während sich ihre Sicherheit verstärkt. Um dieses Ziel bestmöglich erreichen zu können, wurden Blockchain-Plattformen nach den gewichteten Kriterien Smart Contracts, Öffentlichkeit, Gebühren, Blockzeit und Knotenzahl bewertet. Dadurch ergab sich, dass die Ethereum Blockchain nach dem Bewertungsmaßstab der xpecto/talonec am besten für die Umsetzung des Tokensales in der Blockchain eignet. Nach der Festlegung auf die Ethereum Blockchain wurde für Vermittler und Anleger je ein Konzept erarbeitet. Im Konzept für den Anleger wurde sich damit auseinandergesetzt wie der Anleger mit und ohne eines bereits vorhandenen Ethereum-Wallet Sachwertanlagen erwerben und anschlie- ßend handeln kann. Des Weiteren wird dem Anleger angeboten, erzeugte Zugangsdaten bei der xpecto/talonec GmbH sicher aufzubewahren. Beim Konzept des Vermittlers ging es darum, wie er seine Produkte in Form eines Smart Contracts in der Ethereum Blockchain veröffentlichen und auch im Nachhinein noch verwalten kann. Im letzten letzten Schritt wurden die erarbeiteten Konzepte in Form eines Smart Contracts umgesetzt. Dieser wurde in der Ethereum eigenen Programmiersprache Solidity geschrieben. Der Tokensale in der Blockchain wird bereits von einigen Kunden der xpecto/talonec GmbH erwartet. Produkte in Form von Smart Contracts können bereits in Ethereum platziert werden. Auch der Kauf und Handel dieser Tokens ist möglich. Noch im März 2020 soll der Tokensale in der Blockchain in Betrieb gehen. Dann soll ein Produkt, welches über den Tokensale in der Blockchain vertrieben werden soll, von der Bundesanstalt für Finanzdienst- leistungsaufsicht fertig überprüft worden sein. Mit der Freigabe dieses Produktes wird die letzte Hürde für den Tokensale in der Blockchain genommen.
Inhaltsverzeichnis
1 Begriffserklärung 1
1.1 xpectoOnline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Die Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 CAP-Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Partitionstoleranz . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Smart Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Block-Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Einführung 6
2.1 Die Firma xpecto talonec GmbH . . . . . . . . . . . . . . . . . . . . . 6
2.2 Ziel der Bachelorarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Bisheriges Vorgehen der Online-Fondzeichnung . . . . . . . . . . . . 7
2.4 Erwartungen an den Tokensale in der Blockchain . . . . . . . . . . . 8
3 Auswahl der geeigneten Blockchain Plattform 9
3.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Vorbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Smart Contract Plattform (Must-have) . . . . . . . . . . . . . . 10
3.3.2 Öffentlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 Gebühren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.4 Blockzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.5 Knotenanzahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Kandidaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.2 Vorauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Konzept 23
4.1 Tokenisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Prozessteilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Zeichnungsablauf mit Ethereum . . . . . . . . . . . . . . . . . . . . . 26
4.4 Erstellung eines neuen Produktes . . . . . . . . . . . . . . . . . . . . . 28
5 Implementierung Smart Contract 30
5.1 Überprüfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1 Ist der Funktionsaufrufer Issuer oder Emittent? . . . . . . . . 30
5.1.2 Zeitstempel Überprüfung . . . . . . . . . . . . . . . . . . . . . 30
5.1.3 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.4 Pausierung des Smart Contracts . . . . . . . . . . . . . . . . . 31
5.1.5 Bestandsüberprüfung bei Token- Übertragungen . . . . . . . 31
5.1.6 Gesamttokenbestand bei Token- Erstübertragungen . . . . . . 31
5.2 Konstruktor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Tokentransfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Token-Erstübertragung zum Kunden . . . . . . . . . . . . . . . . . . . 34
5.5 Whitelisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 Kontostandabfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.7 Tokenerzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8 Tokenauflösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.9 Zerstörung des Smart Contracts . . . . . . . . . . . . . . . . . . . . . . 39
5.10 Austauschen des Emittenten- und des Registerwallets . . . . . . . . . 40
5.11 Probleme und Herausforderungen . . . . . . . . . . . . . . . . . . . . 41
5.11.1 Mitgegebene Zeitstempel . . . . . . . . . . . . . . . . . . . . . 41
5.11.2 Synchronisation der Historie mit den Kontoständen . . . . . . 42
6 Verwendung und Ausblick 43
6.1 Verwendung des Tokensales in der Blockchain . . . . . . . . . . . . . 43
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Abbildungsverzeichnis 46
Tabellenverzeichnis 47
Glossar 48
Akronyme 50
1 Begriffserklärung
1.1 xpectoOnline
Wie der Name schon vermuten lässt, bietet xpecto-Online die Web Lösung analog zu
xpectos Desktop-Anwendungen an. Sie lässt sich nahtlos in die bestehenden Web-
sites und/oder Anleger- bzw. Vermittlerportale der xpecto/talonec Kunden einbin-
den. Eine große Besonderheit bieten die dynamischen Anpassungsmöglichkeiten
der Anforderungen des einzelnen Kunden. Grundlegend kann man xpecto-Online
in drei Hauptbestandteile gliedern.
Online-Zeichnung
bietet Emittenten ein papierloses Verfahren, um beliebige Sachwertanlagen im In-
ternet zu zeichnen. Dabei wird eine vollständige Integration der jeweiligen aktuel-
len rechtlichen Anforderungen zur Verfügung gestellt. Je nach Emittent können die
Prozesse hinter der Online-Zeichnung nach den Wünschen des Vertriebspartners
angepasst werden.
Webportal für Vermittler
ermöglicht es den Kunden von xpecto, einen schnellen und umfassenden Überblick
ihrer Vorgänge und Verwaltung zu erlangen. Dazu gehört beispielsweise die Über-
sicht der Kunden des Vertriebspartners, ihrer Verträge und ihrer letzten Ereignisse.
Webportal für Anleger
stellt dem Kunden eine Übersichtsplattform bereit, welche Ereignisse, Verträge und
zugehörige Dokumente zur Verfügung stellt.
11.2 Die Blockchain
Abb. 1.1: Blockchain Prinzip
Die Blockchain ist eine Technologie, mit der sich Daten verteilt speichern lassen.
Dabei verwendet sie eine Reihe bewährter Verfahren, welche in den folgenden
Punkten genauer erörtert werden. All diese Punkte verfolgen das Ziel, die gespei-
cherten Daten vor Manipulationen zu schützen, ihre Integrität zu gewährleisten
und die Ereignisse in der Blockchain für all ihre Teilnehmer transparent zu halten.
Die Blockchain ist ein verteiltes System, welches aus einzelnen Knotenpunkten
besteht. Sie werden auch Nodes oder Knoten genannt und bilden zusammen die
Infrastruktur einer Blockchain. Jeder Knoten enthält eine Kopie der Blockchain,
welche auch Distributed Ledger genannt wird. Das Speichern in der Blockchain
funktioniert nach folgendem Prinzip:
Daten, die in die Blockchain gespeichert werden sollen, werden Transaktionen ge-
nannt. Diese werden zunächst in einem Pool aus Transaktionen gesammelt, bis
sie von einem Miner ausgewählt werden und zu einem Block zusammengefasst
werden. Ein Block besitzt eine gewisse Kapazität oder Blockgröße, welche das
Datenlimit angibt. Die Kapazität eines Blocks ist innerhalb einer Blockchain festge-
legt, kann aber zwischen unterschiedlichen Blockchains variieren. Überschreitet ein
Block sein eigenes Limit, wird er vom Netzwerk abgewiesen. Das ist eine Sicher-
heitsmaßname, welche Distributed Denial-of-Service (DDoS) Attacken verhindert.
Ob ein Miner eine Transaktion zu seinem Block hinzufügt, ist von der Transakti-
on abhängig. Mehrere Miner können ein und die selbe Transaktion gleichzeitig in
ihren Block aufnehmen. Es gibt verschiedene Konzepte, nach denen ein Knoten
autorisiert ist, Blöcke in die Blockchain zu speichern. Eines der meist verbreiteten
Konzepte ist Proof-of-Work. Dabei muss ein Knoten als Erster einen gültigen Hash-
wert finden, um seinen Block der Blockchain mitzuteilen. Ein weiteres Konzept
nennt sich Proof-of-Stake, welches im Abschnitt 2.4 noch genauer erörtert wird.
Auf weitere Konzepte wird im Umfang der Bachelorarbeit aber nicht eingegangen.
2Mit diesem Hashwert soll der Block, sobald er in der Blockchain platziert wurde,
eindeutig identifizierbar sein und gleichzeitig die in ihm gespeicherten Daten wi-
derspiegeln. Das Generieren des Hashes ist ein aufwändiges Verfahren, denn nicht
jeder Hashwert wird von der Blockchain akzeptiert. Der Hashwert muss einem von
der Blockchain vorgewiesenen Muster entsprechen. In der Bitcoin Blockchain muss
er beispielsweise mit einer gewissen Anzahl führender Nullen beginnen. Da eine
Hash-Funktion eine gegebene Datenmenge immer auf dieselbe Zahlenfolge abbil-
det, muss der Miner die Datenmenge folglich abändern können. Um den Bezug zu
den eigenen Daten dabei nicht zu verlieren, wird die Datenmenge in 3 Argumente
aufgeteilt, von denen sich nur eine frei ändern lässt, um dem vorgegebenen Hash-
muster gerecht zu werden.
Das frei wählbare Argument wird Nonce genannt. Der Nonce lässt sich wie eine
Stellschraube für den Hashwert betrachten. Er wird solange inkrementiert, bis er
mit den beiden anderen Argumenten einen Hashwert ergibt, der dem Anforde-
rungsmuster der Blockchain entspricht.
Das Argument, welches die eigenen gespeicherten Daten widerspiegelt ist ebenfalls
ein Hashwert und resultiert aus allen Transaktion die sich im Block angesammelt
haben. Sobald sich also die Daten einer Transaktion, ändern würden, ändert sich
gleichzeitig auch ihr Hashwert und somit die gesamte Eingabemenge der Hash-
Funktion für den Block. Das letzte Argument stellt den Hashwert jenes Blocks dar,
welcher zuvor in der Blockchain gespeichert wurde. Also der Hashwert des Block-
vorgängers. Damit lässt sich auch der Begriff Blockchain erklären. Da der Hashwert
eines Blocks unter anderem auf dem Hashwert seines Vorgängers beruht, bildet sich
eine Kette aus Blöcken. Sollten sich die Daten eines Vorgängerblocks verändern,
so ändert sich auch der Hashwert des Vorgängers, welcher wiederum Argument
des Nachfolgeblocks ist. Dies zieht sich wie ein Dominoeffekt durch die ganze
Blockkette. Die geänderten Hashwerte folgen nun mit höchster Wahrscheinlichkeit
nicht mehr dem geforderten Muster der Blockchain, was die mit ihnen assoziierten
Blöcke ungültig werden lässt.
Der erste Miner, der einen gültigen Hashwert gefunden hat, teilt dies den Knoten-
punkten der Blockchain mit. Sie verifizieren den generierten Hashwert des Miners
und bestätigen ihn bei Erfolg unabhängig von einander. Der Miner hat somit die
Erlaubnis, seinen Block den Nodes der Blockchain mitzuteilen, denn jeder Node
besitzt eine Abbildung der Blöcke, die bereits in die Blockchain geschrieben wur-
den. Das bedeutet, dass alle Daten dezentral und redundant gespeichert sind. Dies
ist ein weiterer Sicherheitsmechanismus der Blockchain. Besitzt ein Node eine ma-
nipulierte Version der Blockchain, so würde dieser sofort ausgebessert und von
den umliegenden Nodes berichtigt werden, indem die manipulierte Version mit
der richtigen überspielt wird. Richtig ist in der Blockchain, was die Mehrheit vor-
gibt. Es ist daher weiterhin möglich, die Blockchain zu manipulieren, allerdings
muss dafür über die Hälfte aller Nodes infiltriert werden, um ihre Kopien mit einer
neuen Wahrheit oder richtigen Version zu ersetzten. Dieses Vorgehen ist unter dem
3Namen 51% Angriff“bekannt (vgl. Lin & Liao 2017, S. 656).
”
1.3 CAP-Theorem
Das CAP-Theorem weißt einem verteilten System drei Eigenschaften vor. Konsis-
tenz, Verfügbarkeit und Ausfalltoleranz. Ein verteiltes System kann zwei dieser
Eigenschaften gleichzeitig erfüllen, jedoch ist es nicht möglich, alle drei Eigen-
schaften zu bedienen. Das CAP-Theorem ist für diese Arbeit interessant, da die
Blockchain-Technologie ebenfalls ein Verteiltes System ist. Es wird Teil der Ar-
beit sein herauszufinden, wie sich die Blockchain in Bezug auf das CAP-Theorem
verhält und ob dieses Verhalten Einfluss auf die Lösungsfindung hat.
1.3.1 Konsistenz
Konsistenz bedeutet, dass zu jeder Anfrage die richtige Antwort gesendet wird.
Was im einzelnen Fall richtig ist, hängt von der gewünschten Service Spezifikation
ab. Möglicherweise kann es zu einer Anfrage sogar mehrere richtige Antworten
geben. Die Bedeutung der Konsistenz hängt hier vom jeweiligen Service ab. (vgl.
Gilbert & Lynch 2012, S. 2)
1.3.2 Verfügbarkeit
Verfügbarkeit bedeutet, dass für jede Anfrage eine Antwort garantiert ist. Die Ge-
schwindigkeit der Antwort spielt dabei keine Rolle, obwohl schnelle Antworten
natürlich besser sind als langsame. In vielen realen Systemen sind zu langsame
Antworten genau so schlecht wie gar keine Antwort. (vgl. Gilbert & Lynch 2012,
S. 2)
1.3.3 Partitionstoleranz
Partitionstoleranz besagt, dass das System auch dann noch weiter arbeiten kann,
wenn Teile des Netzes nicht mehr miteinander kommunizieren können. Das kann
durch den Verlust von Nachrichten, den Ausfall einzelner Netzknoten oder den
Abbruch von Verbindungen im Netz auftreten (vgl. Simon 2000, S. 4).
1.4 Smart Contracts
Smart Contracts sind Verträge, welche durch einen Algorithmus definiert sind.
Das hat den Vorteil, [...] dass Leistung und Gegenleistung durch die Programm-
”
logik vorgegeben [...]“(Kaulartz & Heckmann 2016, S. 618) wird. Dadurch wird
die Interaktion mit dem Menschen gering gehalten, welche als unzuverlässig oder
riskant angesehen wird. Auch müssen die (menschlichen) Vertragsparteien einan-
der kein Vertrauen schenken - sie vertrauen lediglich darauf, dass die Maschine
4funktioniert (Kaulartz & Heckmann 2016, S. 618). Dieses Prinzip findet so auch bei
einigen Blockchain Implementierungen Anwendung. So ist es auf der Ethereum
Blockchain beispielsweise möglich, in der Ethereum eigenen Sprache Solidity“,
”
Smart Contracts zu programmieren, in Bytecode zu kompilieren und anschließend
in der Etherium Virtual Machine (EVM) auszuführen. Der kompilierte Bytecode
wird dabei im Ledger von Ethereum gespeichert (vgl. Kaulartz & Heckmann 2016,
S. 91). Smart Contracts reagieren auf vordefinierte Ereignisse mit einer vordefinier-
ten Aktion. Ein Ereignis oder eine Aktion kann Beispielsweise eine Transaktion in
der Blockchain sein.
1.5 Block-Zeit
Block-Zeit nennt man die Zeit, welche die Blockchain benötigt, um einen gültigen
Hashwert für einen Block zu finden. In der Blockchain gibt es einen Richtwert,
wie viele Blöcke innerhalb einer gewissen Zeit geschrieben werden sollten. Dieser
Richtwert wird geschätzte Block-Zeit genannt. Nun wird gemessen, wie viel Zeit
vergeht, bis die gültigen Hashes für eine gewisse Anzahl von Blöcken gefunden
wurden. Hier ist die Rede von der durchschnittlichen Block-Zeit. Es wird versucht,
die Differenz zwischen geschätzter und durchschnittlicher Block-Zeit so gering wie
möglich zu halten. Dies gelingt, indem die Schwierigkeit, einen gültigen Hash zu
finden, angepasst wird. Je schwerer es ist, einen Hash zu finden, umso weniger
Blöcke können in einem Zeitfenster geschrieben werden und umgekehrt.
1.6 Token
Der Begriff Token wird im Kontext der Bachelorarbeit als Wertmarke verstanden.
Da Sachwertanlagen aufteilbar sein müssen, um sie unter verschiedenen Parteien
aufteilen zu können, wird eine Sachwertanlage in einer festen Anzahl Tokens de-
finiert. Sobald ein Anleger Anteile an einer Sachwertanlage erworben hat, werden
ihm Tokens zugewiesen. Die Anzahl der Tokens eines Anlegers spiegeln die Anteile
der Sachwertanlage wieder.
52 Einführung
2.1 Die Firma xpecto talonec GmbH
Die xpecto AG wurde 2001 gegründet, wobei die Idee für xpecto bereits 1994 auf-
kam. Diese entstand durch einen Programmierauftrag während des Studiums von
Harald Elsberger. Die xpecto/talonec GmbH gibt es in diesem Sinne erst seit 2014.
Bis dato gingen die in Landshut ansässige xpecto AG und die talonec business solu-
tions GmbH noch getrennte Wege, bis sie sich dann auf eine Partnerschaft einigten.
Mittlerweile beschäftigt sich die Firma xpecto talonec GmbH schwerpunktmäßig
mit der Entwicklung von Software für den Finanz- und Kapitalanlagenmarkt. Zu
den Kunden zählen unter anderem Emissionshäuser, Finanzbetriebe, Vermögens-
verwalter sowie Fonds- und Treuhandgesellschaften.
Der Zuwachs der Firma ist in den vergangenen Jahren stark angestiegen und die
Firma kann zum jetzigen Zeitpunkt bis zu 50 beschäftigte Mitarbeiter zählen, wel-
che sich auf die Standorte Landshut und Krailling verteilen.
Der Online Bereich ist die neueste Errungenschaft der xpecto/talonec GmbH und ein
wichtiges Standbein für die Firma geworden, welche ihr einen neuen Vertriebska-
nal bietet. Da sich der Trend immer mehr in Richtung der Onlineportale verschiebt,
wird dieser Bereich auch stets ausgebaut und erweitert. Dieser bietet zahlreiche
Vorteile gegenüber den plattformabhängigen Softwarelösungen und verspricht ei-
ne Zukunft mit viel Potential. Ein bedeutender Bestandteil der Online Services sind
die Online-Zeichnungen, bei denen sich Beteiligungen an Sachwertfonds über das
Internet erwerben lassen.
2.2 Ziel der Bachelorarbeit
In den bisherigen Prozessen einer Online-Fondszeichnung werden Bankdepots
vom Kunden benötigt, um Sachwertanlagen zu erwerben. Ziel dieser Bachelorarbeit
wird es sein herauszufinden, ob sich diese Bankdepots in die Blockchain verschie-
ben lassen. Dabei werden mehrere Blockchain-Plattformen betrachtet und anhand
ihrer Eigenschaften evaluiert, welche Plattform sich am besten eignet. Unter an-
derem muss auch betrachtet werden, ob sich die rechtlichen Rahmenbedingungen
in einer Blockchainumgebung einhalten lassen. Findet sich eine Plattform, die den
Ansprüchen der xpecto/talonec GmbH genügt, und lässt sich das Vorhaben in den
gesetzlichen Rahmenbedingungen realisieren, wird eine Prototypen-Schnittstelle
6vom bestehenden Zeichnungsprozess zur geeigneten Blockchain-Plattform entwi-
ckelt und die weitere Machbarkeit untersucht.
2.3 Bisheriges Vorgehen der Online-Fondzeichnung
Möchte ein Kunde Anteile an einem Fonds online erwerben, so registriert er sich
zunächst über ein Online-Portal eines xpecto/talonecs Vertriebspartners. Anschlie-
ßend kann der Kunde seine Zeichnung vornehmen, welche den Zeichnungsprozess
in der Middleware des xpecto/talonec Servers auslöst. Es ist abhängig vom Emitten-
ten, ob ein Kunde nach oder während des Zeichnungsprozesses über verschiedene
Ebenen überprüft wird. Bei der Überprüfung hat der Emittent die Möglichkeit,
Nacharbeiten beim Kunden anzufordern, die Zeichnung abzulehnen oder anzu-
nehmen und den Vertragsstatus folglich aktiv zu schalten, wie es in der Abbildung
2.1 beim Vertriebspartner abgebildet ist. Für eine Zeichnung benötigt der Kunde
ein Bankdepot, dem die zukünftig erworbene Sachwertanlagen zugeordnet wer-
den können. Ist dieses zum Zeitpunkt der Zeichnung noch nicht vorhanden, so
müssen diese Daten nachgereicht werden. Manche Emittenten bieten den Service,
Bankdepots für Kunden, die noch keines besitzen, anzulegen. Sobald die Daten für
ein vorhandenes Bankdepot bereitstehen, können die erworbenen Sachwertanlagen
auf das Depot gebucht werden.
Abb. 2.1: Ablauf Onlinezeichnung xpecto AG (Elsperger 2018)
72.4 Erwartungen an den Tokensale in der Blockchain
Wenn es darum geht, Finanzen zu verwalten, sind die Eigenschaften Manipulati-
onssicherheit, Zuverlässigkeit, Verfügbarkeit und Transparenz essentiell. In der mo-
dernen Menschheitsgeschichte wurden Banken diese Eigenschaften zugeschrieben.
Sie wurden mittels ihrer Infrastruktur (Gebäude, Tresore, internationale Verbin-
dungen) diesen Anforderungen weitgehend gerecht. Ereignisse wie Bankenkrisen
haben allerdings immer wieder deutlich gemacht, dass Banken den Anforderun-
gen nicht zuverlässig gerecht werden können und daher nur eine Näherungslösung
für das Problem der Finanzverwaltung sind. Die Technologie der Blockchain ver-
spricht, diese Eigenschaften durch technische Verfahren einhalten zu können. So
wird das Vertrauen keinem dritten Mittelsmann, sondern einem transparenten
Mechanismus geschenkt, der frei von Eigeninteressen seinen vorbestimmten Re-
geln folgt. Weil Prozesse in der Blockchain nicht von Menschen gesteuert werden
müssen, fällt gleichzeitig ein enormer Kostenfaktor weg, der sich bei Banken bei-
spielsweise in Form von Kontoführungsgebühren äußert. Mit dem Einbinden der
Blockchain-Technologie sollen genau diese Vorteile genutzt werden. Von diesen
Vorteilen würden Kunden direkt profitieren, indem ihnen Kosten und Risiken er-
spart bleiben. Aber jede Technologie hat auch ihre Schwächen. Und da es sich bei
der Blockchain-Technologie um eine noch sehr junge Technologie handelt, mögen
viele Schwächen noch unbekannt sein. Des Weiteren verändern sich die Konzep-
te der Blockchain in verschiedenen Ausführungen stets weiter, und es lässt sich
schwer abschätzen, welche sich durchsetzen. Es besteht die Gefahr, auf ein Kon-
zept zu vertrauen, welches sich als Sackgasse entpuppt. Beispielsweise sichern
viele Implementierungen ihren Ledger mit dem Proof-of-Work Konzept ab, was
allerdings einen hohen Rechenaufwand und starke Ineffizienz zur Folge hat. Al-
ternative Konzepte wie Proof-of-Stake haben dieses Problem gelöst, Proof-of-Stake
läuft aber Gefahr, reiche Validatorknoten für das Blockforging zu bevorzugen und
sie dabei noch reicher zu machen. Das kann zu einer stärkeren Zentralisierung
der Blockchain führen. Es wird deutlich, dass unterschiedliche Ausführungen auch
unterschiedliche Schwächen und Stärken aufweisen, die es zu erkennen und zwi-
schen ihnen abzuwägen gilt. Welche Umsetzung sich in Summe am meisten für
die Umsetzung des Tokensales in der Blockchain für xpecto/talonec eignet, wird im
nächsten Kapitel ersichtlich.
83 Auswahl der geeigneten
Blockchain Plattform
3.1 Vorgehen
Um eine Blockchain zu finden, die den im Abschnitt 2.4 genannten Erwartungen
bestmöglich erfüllt, werden in diesem Kapitel Bewertungskriterien aufgestellt und
erläutert. Anschließend wird jeder Anforderung eine Gewichtung zugeteilt werden.
Die Gewichtung wird auf einer Skala von 1 - 10 getroffen. 1 stellt damit die niedrigs-
te Gewichtung dar, während 10 die höchste Priorität eines Kriterium repräsentiert.
Zusätzlich werden Must-have Kriterien formuliert. Kann eine Blockchain nicht alle
Must-have Kriterien aufweisen, scheidet diese bereits in der Vorfilterung aus und
wird nicht weiter beurteilt. Für alle anderen Blockchains wird eine Gesamtwertung
mittels der Formel 3.1 errechnet. Die Prioritäten der einzelnen Kriterien wurden
alle in Absprache mit dem Unternehmen xpecto/talonec GmbH getroffen, um eine
Blockchain passend zu den Anforderungen der Firma zu finden. Anschließend wer-
den eine Reihe vorhandener Blockchains diesen Anforderungen gegenübergestellt.
G ∈ {1, ..., 10} Gewichtung
z ∈ [0, 1] Erfüllung
n∈N Anzahl Anforderungen
Xn
Gi · zi Gesamtwertung (3.1)
i=1
Die Blockchain mit der höchsten Gesamtwertung, wird die geeignete Blockchain-
Umgebung repräsentieren. Im Folgenden werden die Kriterien aufgezeigt, beschrie-
ben und anschließend gewichtet.
3.2 Vorbemerkung
Nach dem CAP-Theorem von Eric Brewer, welches im Abschnitt 1.3 genannt wurde,
können nur 2 der Eigenschaften Konsistenz, Verfügbarkeit oder Partitionstoleranz
in einem verteilten System erfüllt werden. Jedes verteilte System trifft mit seiner
Architektur die Entscheidung, eine Eigenschaft zu vernachlässigen. Mit dem To-
kensale in der Blockchain wird sich auf die Blockchain-Technologie gestützt, die
sich für eine Architektur der Verfügbarkeit und Partitionstoleranz entschieden hat.
9Sie behält die Verfügbarkeit bei, während sie inkonsistent ist und versucht den
Zeitversatz so gering wie möglich zu halten, den es benötigt, um die Daten wie-
der auf einen konsistenten Stand zu bringen. Auf die Entscheidungen, die das
CAP-Theorem betreffen, kann mit der Priorisierung bestimmter Blockchain Eigen-
schaften keinen Einfluss mehr genommen werden.
3.3 Anforderungen
3.3.1 Smart Contract Plattform (Must-have)
Wenn ein Bankdepot in der Blockchain umgesetzt werden soll, müssen dafür Regeln
und Abläufe definiert werden. Was passiert wenn Person A eine Summe S an Person
B überweist? In manchen Blockchains wird das durch Smart Contracts ermöglicht.
Hier sollen die Bedingungen und Abläufe formuliert werden, um ein Bankdepot
nutzbar und verwaltbar zu gestalten.
Fazit
Da, wie schon erwähnt, nicht alle Blockchains Smart Contracts unterstützen, muss
diese Anforderung als Must-have“Kriterium formuliert werden.
”
3.3.2 Öffentlichkeit
Dezentrales und redundantes Speichern von Daten sind mit die wichtigsten Argu-
mente für das zukünftige Abbilden der Bankdepots in der Blockchain. Je größer die
Infrastruktur einer Blockchain ist, umso dezentraler und redundanter können die
gespeicherten Daten abgelegt werden. Daher wächst analog zur Blockchain auch
der damit verbundene Sicherheitsfaktor und Aufwand, Daten zu manipulieren.
Aber auch die Unabhängigkeit spielt in diesem Kriterium eine Rolle. Mit dem To-
kensale in der Blockchain sollten auch dritte Institutionen wie Banken wegfallen,
um zusätzliche Abhängigkeiten zu vermeiden. Die Öffentlichkeit einer Blockchain
hat darauf direkten Einfluss. Denn die Größe der Blockchain sollte sich auf eine
ebenso große, voneinander unabhängige, Gruppe Knotenbetreiber verteilen. Eine
große Blockchain, welche zu 51% von einer Institution betrieben oder verwaltet
wird, kann nicht mehr als vertrauenswürdig angesehen werden, da damit ein im-
plizites Vertrauen in die betreibende Institution einhergeht. Die Wahrscheinlichkeit,
dass ein solches Szenario eintreten kann, sinkt mit der Größe der Blockchain und da-
her auch die Abhängigkeit zu einzelnen Institutionen. Es gibt zwei unterschiedliche
Blockchain Konzepte, die sich auf die genannten Punkte unterschiedlich auswirken.
Öffentliche Blockchain
Wie der Name bereits verrät, gehört die öffentliche Blockchain keiner einzelnen
Institution. Sie gehört der Öffentlichkeit, und jeder kann als Knoten im Entschei-
dungsprozess der Blockchain teilnehmen. Alle Nutzer dieser unregulierten Knoten
10erhalten eine Kopie der Blockchain auf ihren lokalen Knoten und nutzen eine
verteilte Einigkeit über den Entscheidungsmechanismus. Dieser entscheidet über
den möglichen Zustand oder Inhalt aller Knoten in der Blockchain (vgl. Bashir
2017, S. 33). Die zur Zeit größten und etabliertesten Blockchains, Bitcoin mit 9426
Knoten (Yeow 2019) und Ethereum mit 8509 Knoten (ethernodes.org 2019) verfol-
gen beispielsweise das öffentliche Blockchain Prinzip. Mit der Verteilung auf die
öffentlichen Nutzer ist die Verfügbarkeit ebenfalls redundant sichergestellt. Ein
öffentliches Netzwerk, mit Knoten verteilt über die ganze Welt, ist robuster ge-
genüber geographisch bezogenen Ereignissen wie beispielsweise Stromausfällen,
Naturkatastrophen oder sogar politischen Regulierungen.
Private Blockchain
Auch hier verrät der Name bereits seine Bedeutung. Private Blockchains obliegen
gewissen Regulierungen. Sie stehen nur für ein Konsortium oder eine Gruppe
individueller Personen zur Verfügung. Dies ist beispielsweise sinnvoll für eine
Organisation, welche Daten untereinander teilen möchte und dabei die Vorteile der
Blockchain für sich nutzen möchte. So ist die Organisation von der Öffentlichkeit
unabhängig, kann ihre Blockchain komplett selber verwalten und ist ganz allein
für sie verantwortlich. Blockchains wie HydraChain oder Quorum fallen in die
Kategorie der privaten Blockchains (vgl. Bashir 2017, S. 33).
Fazit
Das Ziel, ein Bankdepot in eine Blockchain zu verlagern, ließe sich in einer priva-
ten wie auch einer öffentlichen Blockchain realisieren. Da Abhängigkeiten in einer
öffentlichen Blockchain allerdings breiter gestreut sind und die Sicherheit entschei-
dend größer ist als die einer privaten, ist der öffentlichen Blockchain der Vorzug
zu geben. Öffentliche Plattformen haben in der Regel einen größeren Verbreitungs-
grad. Das wirkt sich positiv auf die Knotenanzahl aus, siehe Abschnitt 3.3.5. Eine
große Blockchain bietet eine Streuung in der geografischen Verteilung, was vor
lokalen Krisen, wie beispielsweise Stromausfällen oder Erdbeben, absichert. Das
führt zu einer höheren Verfügbarkeit und geringeren Abhängigkeit. Daher eine
Gewichtung von 5 Punkten.
3.3.3 Gebühren
Wie bei einem klassischen Bankdepot fallen auch in der Blockchain Gebühren an,
die bezahlt werden müssen. Sie entlohnen die Personen, welche die Hashes der zu
schreibenden Blöcke berechnen. Bei diesen Berechnungen fallen Kosten an, welche
durch die Gebühren gedeckt werden sollen. Dadurch wird einer Transaktion selber
ein Wert verliehen und Transaktionen werden vom Anwender überlegter und nicht
verschwenderisch durchgeführt. Gleichzeitig werden dadurch DDoS Angriffe für
Angreifer unwirtschaftlich und die Blockchain somit sicherer.
11Zu hohe Gebühren wiederum verschaffen einem Depot in der Blockchain keinen
wirtschaftlichen Vorteil gegenüber dem herkömmlichen Bankdepot. Hier muss
also ein Bewertungsmaßstab gewählt werden, der mit sinkenden Gebühren das
Gebührenkriterium zunehmend erfüllt. Keine Gebühren sind für ein Unternehmen
wirtschaftlich immer von Vorteil, weshalb keine Gebühren das Gebührenkriterium
vollständig erfüllen. Weil sich Gebühren in einer Blockchain mit der Zeit an den
Markt anpassen und variieren, kann nur der Kurs betrachtet werden, welcher zum
Zeitpunkt der Bachelorarbeit aktuell war.
Bewertungsmaßstab
Ziel ist es, herkömmliche Transaktionsgebühren von Banken zu unterbieten. Die
Obergrenze des Bewertungsmaßstabs spiegelt daher die durchschnittlichen Trans-
aktionsgebühren verschiedener Banken wider. Die Transaktionsgebühren der Block-
chain und die der Banken lassen sich allerdings nicht im selben Maßstab verglei-
chen. Denn die Transaktionsgebühren der Blockchain sind, anders als die der Ban-
ken, unabhängig von der Transaktionssumme. Die Transaktionsgebühren der Ban-
ken ergeben sich prozentual aus der Transaktionssumme. Der Graph 3.1 stellt den
durchschnittlichen Gebührenverlauf verschiedener Bankangebote in Abhängigkeit
des Ordervolumens dar. Angaben wie Orderanzahl pro Jahr, Orderanteile im In-
ternet und Depotvolumen sind fix. Es wird von 12 Ordern pro Jahr ausgegangen,
davon alle im Internet und mit einem Depotvolumen von 20.000€. Dabei wird sich
auf Daten des Vergleichsportals verivox bezogen (verivox 2019). Der Quellcode,
mit dem diese Daten erfasst und analysiert wurden, befindet sich mit den Ver-
gleichsdaten im Anhang. Wie gut ein Blockchain Kandidat das Gebührenkriterium
erfüllt, wird mit der Formel 3.2 bestimmt. Um negative Werte zu vermeiden, wird
die Erfüllung aller Kandidaten, deren Transaktionsgebühren fm überschreiten, mit
0 bewertet.
12Abb. 3.1: Durchschnittliche Ordergebühren abhängig vom Ordervolumen
30
Ordergebühr/Ordervolumen
25.1
Ordervolumen [€]
15
7.83
0 0.5 1 1.5 2
Kosten pro Order [€] 4
·10
fm ∈ R+ Gebühren max.
fi ∈ R+ Gebühr Kandidat
fi
1− Erfüllung (3.2)
fm
Fazit
Weil niedrige Gebühren ein wichtiges Argument für den Tokensale in der Block-
chain sind, darf dieses Argument in der Bewertung nicht vernachlässigt werden.
Da aber erwartet wird, dass die Blockchaingebühren generell erheblich günstiger
ausfallen, als bei den Ordergebühren der Banken und sich daher nicht stark von
einander abheben werden, wird die Priorisierung auf 5 Punkte festgelegt.
3.3.4 Blockzeit
Je kürzer die Blockzeit desto mehr Transaktionen können in kürzerer Zeit durch-
geführt werden. Weil Transaktionszeiten in der Blockchain, verglichen mit denen
der Banken, um vieles schneller sind, ist die kurze Bearbeitungszeit von Transak-
tionen ebenfalls ein Vorteil, der für die Blockchain spricht. So benötigt eine Trans-
aktion in der Bitcoin Blockchain durchschnittlich 10 Minuten (Luxembourg 2017)
und eine Transaktion in der Ethereum Blockchain zwischen 10 und 20 Sekunden
(Etherscan.io 2019) bis zur Bestätigung.
Bewertungsmaßstab
Wie schon bei den Gebühren gilt auch bei beim Blockzeit Kriterium: Je geringer,
desto besser.
13Um einen Bewertungsmaßstab zu erstellen, welcher angeben soll, wie gut eine
Blockchain das Blockzeit Kriterium erfüllt, werden die durchschnittlichen Block-
zeiten der Blockchain Kandidaten gesammelt. Alle Kandidaten werden mit dem
Kandidaten der längsten Blockzeiten verglichen. Die Erfüllung des Blockzeit Kri-
teriums wird anhand der Formel 3.3 ermittelt.
tm ∈ R+ Blockzeit max.
ti ∈ R+ Blockzeit Kandidat
ti
1− Erfüllung (3.3)
tm
Fazit
Die Priorität für das Blockzeit Kriterium fällt nicht so stark ins Gewicht, da es sich
hierbei eher um ein nice to have “Feature handelt. Daher eine Priorität von nur 3
”
Punkten.
3.3.5 Knotenanzahl
Die Blockchain ist ein verteiltes System, welches sich aus Knoten zusammensetzt.
Daher lässt sich an dem Kriterium der Knotenanzahl die Größe der Blockchain be-
urteilen. Die Knoten in öffentlichen Blockchains werden von freiwilligen Personen
und Organisationen betrieben, welche einen Client der entsprechenden Blockchain
auf ihrem System laufen lassen. Dieser Client bestätigt Transaktionen und Blöcke
anderer Knoten, validiert diese und leitet sie dann an andere Knoten weiter. Die
gesamte Rechenlast der Blockchain verteilt sich auf ihre einzelnen Knoten. Aus je
mehr Knoten eine Blockchain also besteht, desto besser verteilt sich ihre Rechen-
last, steigert ihre Verfügbarkeit und umso robuster ist sie gegenüber störenden
Ereignissen. Diese störenden Ereignisse können beispielsweise Angriffen, Natur-
katastrophen oder lokalpolitischen Vorfällen. Dabei ist es von Vorteil, wenn sich
das Knotennetzwerk über die ganze Welt verteilt. Da die Knoten öffentlicher Block-
chains ausschließlich von Freiwilligen betrieben werden, lässt sich anhand der
Knotenanzahl auch auf die Größe der Community schließen, welche hinter der
Blockchain steht. Sie kann ein Indikator für den zukünftigen Entwicklungsverlauf
und Erfolg sein.
Bewertungsmaßstab
Da Robustheit, Verfügbarkeit und Sicherheit mit Zunahme der Knotenanzahl steigt,
erfüllt eine Blockchain mit vielen Knoten das Kriterium der Knotenanzahl besser
als eine Blockchain mit wenigen Knoten. Die Erfüllung wird mit der Formel 3.4
errechnet.
14nm ∈ R+ Knotenzahl max.
ni ∈ R+ Knotenzahl Kandidat
ni
Erfüllung (3.4)
nm
Fazit
Da die Knotenanzahl ein ausschlaggebender Indikator für die Sicherheit, Perspek-
tive, Verfügbarkeit und Robustheit einer Blockchain ist, fällt dieses Kriterium ent-
sprechend stark ins Gewicht. Daher werden hier 7 Prioritätspunkte vergeben.
153.4 Bewertung
3.4.1 Kandidaten
Für die Evaluierung werden aufgrund eigener Recherchen die aktuell bekanntesten
Blockchains zusammengetragen und bewertet.
Folgende Kandidaten werden betrachtet:
Ethereum EOS
Kadena TRON
Openchain Stellar
Bitcoin nem
Dune waves
Litecoin Cardano
Ripple Cosmos
Rootstock Tezos
NEO
Tab. 3.1: Blockchain Kandidaten Auswahl
Nach den oben definierten Mindestanforderungen müssen alle Kandidaten Smart
Contracts unterstützen. Daher durchlaufen alle Kandidaten eine Vorauswahl, um
jene Kandidaten, die dieses Kriterium nicht erfüllen, gleich ausschließen zu können.
163.4.2 Vorauswahl
Kandidaten welche keine Smart Contracts unterstützten werden in der Vorauswahl
aussortiert.
Ausgeschiedene Kandidaten
Die Blockchains Bitcoin, Litecoin und Ripple(Huffman 2019) unterstützen keine
Smart Contracts und scheiden daher in der weiteren Evaluierung aus.
Weiterbestehende Kandidaten
Übrig bleiben:
Ethereum (ethereum.org 2020, vgl.)
Kadena (vgl. Bashir 2017, S. 506)
Openchain (openchain.org 2019, vgl.)
Rootstock (vgl. Bashir 2017, S. 520)
NEO (neo.org 2019, vgl.)
EOS (Smart Contract Development n.d., vgl.)
TRON (Smart Contract Deployment n.d., vgl.)
Stellar (Stellar Smart Contracts n.d., vgl.)
nem (NEMT ECHNOLOGY n.d., vgl.)
waves (RIDE n.d., vgl.)
Cardano (blockchaincenter.net 2019, vgl.)
Tezos (vgl. Bashir 2017, S. 523)
Dune (vgl. The Dune Network 2019, S. 1)
Tab. 3.2: Blockchain Kandidaten nach Vorauswahl
173.4.3 Analyse
Blockchain öff./priv. (5 ) Gebühren (5 ) Blockzeit (3 ) Knoten (7 )
12Gwei =ˆ
Ethereum öffentlich 0.00000159852€
15sec. 8509
1.60 × 10−6 € 15sec. 8509
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
Kadena beides noch nicht bekannt 30 sec. -
30sec.
Score: 5∗1 3 ∗ (1 − )
tm
Openchain öffentlich 0,-€ 319sec. 34
0, −€ 319sec. 34
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
65Mwei =ˆ
Rootstock öffentlich 32sec. 17
0,00000000837€
8.37 × 10−9 € 32sec. 17
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
NEO 0.001GAS =ˆ
öffentlich 0,000916807€
21sec. 27
9.17 × 10−4 € 21sec. 27
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
EOS öffentlich 0EOS =
ˆ 0,-€ 0,5sec. 21
0,-€ 0.5sec. 21
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
TRON öffentlich 0TRX =
ˆ 0,-€ 3sec. 906
0,-€ 3sec. 906
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
0.00001XLM =ˆ
Stellar öffentlich 5sec. 145
0,0000004770174€
4.77 × 10−7 € 5sec. 145
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
1.25XEM =ˆ
NEM beides 0,0396225€
60sec. 418
3.96 × 10−2 € 60sec. 418
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
0.001Waves =
ˆ 0,000045232
Waves öffentlich 60sec. 380
€
4.52 × 10−5 € 60sec. 380
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
Tab. 3.3: Blockchain Kandidaten Analyse Teil 1
18Blockchain öff./priv. (5 ) Gebühren (5 ) Blockzeit (3 ) Knoten (7 )
0,18ADA= ˆ
Cardano public 20sec. -
0,00529€
5.29 × 10−3 € 20sec.
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − )
7.83€ tm
0.025uatom=ˆ
Cosmos public 7sec. 49
0,0000000965€
9.65 × 10−8 € 7sec. 49
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
Tezos (Tot) - - - -
Score: 0
0,468571429d =
ˆ
Dune public 60sec. 65
0,00001827€
1.82 × 10−5 € 60sec. 65
Score: 5∗1 5 ∗ (1 − ) 3 ∗ (1 − ) 7∗( )
7.83€ tm nm
Tab. 3.4: Blockchain Kandidaten Analyse Teil 2
193.4.4 Auswertung
Für die Auswertung der Kandidaten werden die erreichten Kriterienpunkte zusam-
mengetragen und zu einer Gesamtpunktzahl aufaddiert. Anschließend werden sie
in der Tabelle 3.5 nach der erreichten Gesamtpunktzahl sortiert. Der Kandidat mit
den meisten Punkten soll die best geeignetste Blockchainplattform sein, den To-
kensale in der Blockchain für die Firma xpecto/talonec umzusetzen.
Rang Blockchain Gesamtpunktzahl
1 Ethereum 19,86
2 TRON 13,72
3 Stellar 13,07
4 EOS 13,01
5 Cosmos 12,97
6 NEO 12,82
7 NEM 12,75
8 Waves 12,71
9 Rootstock 12,71
10 Dune 12,49
11 Openchain 10,03
– Cardano –
– Kadena –
– Tezos (Tot) –
Tab. 3.5: Blockchain Kandidaten Auswertung
Für die Kandidaten Cardano, Kadena und Tezos war es nicht möglich alle benötigten
Daten zu ermitteln. Genaueres wird später im Fazit behandelt. Daher konnte für sie
keine Gesamtpunktzahl errechnet werden und dementsprechend fallen sie aus der
Auswertung und dem Ranking heraus. Ethereum erreichte 19,89 von 20 möglichen
Punkten und belegt damit Platz eins. Ethereum qualifiziert sich somit für die Block-
chainplattform, mit der der Tokensale in der Blockchain umgesetzt werden soll.
203.5 Fazit
Ziel war es eine geeignete Blockchain Plattform nach den Anforderungen der xpec-
to/talonec GmbH zu finden. Dabei hat sich herausgestellt, dass die Ethereum Block-
chain jene unter den betrachteten Kandidaten ist, welche den Anforderungen am
besten gerecht wird. Wichtig zu betonen ist, dass die Auswertung der Blockchain
Plattformen speziell den Anforderungen der xpecto/talonec GmbH entsprechen.
Ethereum besitzt mit Abstand die meisten Knoten unter den Blockchain Kandida-
ten, was ausschlaggebend für die Erreichung seiner Höchstpunktzahl war. Doch
obwohl Ethereum der Spitzenreiter ist, muss die Entwicklung der Knotenanzahl
weiterhin kritisch und kontinuierlich beobachtet werden, weil die Zahl wie in Ab-
bildung 3.2 erkennbar ist stark fluktuiert.
Abb. 3.2: Ethereum Verlauf Knotenanzahl (Etherscan.io 2020)
Die Plattformen Cardano, Kadena und Tezos wurden aus der Wertung ausgeschlos-
sen. Das liegt daran, dass manche Eigenschaften der Blockchains sich entweder
nicht ermitteln ließen, Services mancher Blockchains zum Zeitpunkt der Analyse
nicht zur Verfügung standen oder die Plattform selber gar nicht mehr existiert wie
es im Fall Tezos war. Die Einstellung des Tezos Projektes wurde durch eine private
E-Mail Korrespondenz mit einem Tezos Mitarbeiters in Erfahrung gebracht.
Am Beispiel Tezos lässt sich gut verdeutlichen, dass die Zukunftsbeständigkeit von
Blockchain Plattformen nicht garantiert ist. Daher war es in der Analyse wichtig,
einen Eindruck über Verbreitung und Größe der Plattform Kandidaten zu gewin-
nen. Diese sind zwar keine Garantie für eine erfolgreiche oder fortbestehende Zu-
kunft, doch aus ihnen lässt sich ein weiterer Fortbestand und Erfolg ableiten. Dieser
Eindruck sollte über die Eigenschaft der Knotenzahl in die Analyse mit einfließen.
Eine weitere Schwierigkeit der Analyse war, dass sich manche Blockchain Konzep-
21te schwierig, und daher nicht ganz fair, miteinander vergleichen lassen. Kadena
beispielsweise besitzt nicht nur eine lineare Kette an Blockreferenzen, sondern viel-
mehr ein ganzes Netz von Blockreferenzen. Es laufen dabei mehrere Chains parallel,
welche sich gegenseitig referenzieren.3.3
Abb. 3.3: Kadena 3D Blockexplorer (Kadena 3D Blockexplorer 2020)
224 Konzept
Im letzten Kapitel stellte sich heraus, dass die Ethereum Blockchain jene Plattform
ist, mit der sich der Tokensale in der Blockchain realisieren ließe. In diesem Kapitel
geht es darum, ein Konzept auszuarbeiten, wie der Tokensale in der Blockchain im
bestehenden online-Zeichnungsprozess integriert werden soll, welche Prozessteil-
nehmer für den Tokensale in der Ethereum Blockchain notwendig sind und wie ein
Emittent sein Produkt dort platzieren kann.
4.1 Tokenisierung
Nach der BaFin handelt es sich dabei um die digitalisierte Abbildung eines (Vermö-
gens-) Wertes inklusive der in diesem Wert enthaltenen Rechte und Pflichten sowie
dessen hierdurch ermöglichte Übertragbarkeit (bafin.de 2019, vgl.). Dieser Schritt
wird benötigt, um Sachwertanteile in der Blockchain später abbilden, handeln, und
zuweisen zu können.
Abb. 4.1: Tokenisierung
234.2 Prozessteilnehmer
Abb. 4.2: Übersicht Tokensale
Registerwallet
Synonyme: Registerführer, Registrar.
Das Registerwallet lässt sich wie die Schnittstelle zwischen Emittentenwallet und
Kundenwallet begreifen und wird von xpecto/talonec verwaltet. Es wird benötigt,
um einen neuen Smart Contract zu erzeugen. Für die Erzeugung fallen Gebühren in
der Ethereum Blockchain an. Diese werden aus dem Registrarwallet bezahlt. Des-
weiteren ist das Registrarwallet in einer Administratorfunktion für den erzeugten
Smart Contract. Damit nicht jeder, der ein Ethereum Wallet besitzt, eine Funk-
tion auf dem Smart Contract durchführen kann, muss der Zugriff auf den Smart
Contract begrenzt werden. Vor Funktionsaufrufen, die nur dem Registerführer vor-
behalten sind, wird zunächst die Walletadresse des Funktionsaufrufer abgefragt.
Kann die Walletadresse dem Registerführer zugewiesen werden, darf er alle Funk-
tionen durchführen für die er autorisiert ist. Funktionen die nur der Registerführer
aufrufen darf sind Beispielsweise kill() 5.9 oder transferRegistrar() 5.10.
modifier onlyIssuer {
require(msg.sender == issuer, "only valid for issuer");
_;
}
Listing 4.1: Walletadressenvergleich zwischen Funktionsaufrufer und
Registerführer
24Emittentenwallet
Synonyme: Emittent, Owner, Issuer.
Das Emittentenwallet hält alle Tokens nach Erzeugung. Für jedes Produkt oder jede
Emission, von der Anteile durch eine Zeichnung erworben werden können, gibt es
ein eigenes Emittentenwallet. Der Wert des Produkts wird in Tokens aufgeteilt. So
lässt sich das Produkt später auf die unterschiedlichen Anteilhaber aufteilen. Das
Emittentenwallet hält zu Beginn alle Tokens, in die das Produkt aufgeteilt wurde.
Kundenwallet Customer“
”
Die Adresse des Kundenwallets wird verwendet, um die vom Kunden erworbenen
Tokens dem Kunden zuzuweisen. Alle Kundenwallets werden dabei in einer Map
festgehalten. Sie ordnet jeder Walletadresse eine Tokenbilanz zu. Beim Kauf oder
Übertragen von Tokens werden diese Änderungen in der Map übernommen.
Systemwallet
Für jede xpectoPro Datenbank sollte ein Systemwallet erzeugt werden. Dieses soll-
te für die automatische Erzeugung der Kundenwallets verwendet werden. Dabei
fließt der Publickey des Systemwallets als Parent in den Kundenwallet mit ein. Die
generierten Wallets nennt man dann HD Wallets. Sie enthalten einen Ableitungs-
pfad. Falls ein Kunde den Privatkey seines Kundenwallets verlieren sollte, wäre
es möglich, den Privatekey zu errechnen. Für die Errechnung würde der extended
Privatekey des Systemwallets aus seinem Mnemonic erzeugt. Dieses Konzept lässt
sich allerdings wegen Vorschriften der BaFin nicht umsetzten. Falls der Private-
key des Kunden verloren gehen sollte, kann dieser daher nicht wiederhergestellt
werden. Alternativ können Tokens auf einem verlorenen Wallet verbrannt werden,
und einem neuen Wallet zugewiesen werden. Tokenverbrennung oder burning be-
schreibt den Prozess, vorhandene Tokens zu zerstören, wie es im Abschnitt 5.8
erläutert wird.
254.3 Zeichnungsablauf mit Ethereum
Der Tokensale soll im bestehenden Online-Zeichnungsprozess der xpecto/talonec
GmbH integriert werden. Der Ablauf ist dabei wie folgt definiert:
Für den Tokensale in der Onlinezeichnung wird ein Wallet des Kunden benötigt,
auf dem die Anteile der Sachwertanlage überschrieben werden können. Besitzt der
Kunde bereits ein solches Wallet, hat er die Möglichkeit, die damit verbundene Wal-
letadresse anzugeben. Anschließend wird die Adresse auf ihre Richtigkeit geprüft.
Dabei muss die Walletadresse mit 0x beginnen. Anschließend wird die Prüfsumme
der Walletadresse überprüft. Dafür muss die Walletadresse groß und kleingeschrie-
bene hexadezimale Buchstaben von A-F enthalten. Ein Prüfsummenabgleichs ist
nicht möglich wenn alle Buchstaben in der Walletadresse klein geschrieben sind, da
die Groß- Kleinschreibung Element des Prüfsummenabgleichs ist. Die Implemen-
tierung des Prüfsummenabgleichs kann unter folgender URL eingesehen werden:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-55.md
Falls ein Kunde noch kein Wallet besitzt, wird eines für ihn erstellt und die Wal-
letadresse dem Kunden zugeordnet. Bei der Erstellung eines Wallet werden auch
Zugangsdaten erstellt. Da dies vertrauliche Daten sind, gibt es zwei Szenarien wie
mit ihnen umgegangen wird.
Verschlüsselt bei der xpecto/talonec GmbH speichern:
Der Kunde hat die Möglichkeit, die erzeugten Zugangsdaten des Wallets bei
xpecto zu speichern. Diese werden mittels PGP und eines gewählten Passworts
des Kunden verschlüsselt gespeichert.
Übermittlung der Zugangsdaten:
Die erzeugten Zugangsdaten können dem Kunden im Browser übermittelt
werden. Die Verantwortung, die Zugangsdaten sicher zu bewahren, liegt nur
noch beim Kunden. Bei xpecto liegen keinerlei Zugangsdaten für das erzeugte
Wallet.
Anschließend erhält der Kunde eine Zahlungsaufforderung für den Erwerb der
Sachwertanteile. Die Zahlung kann per Überweisung oder Lastschrift getätigt wer-
den. Trifft die Zahlung ein, wird folgendes sequentiell überprüft:
1. Wurde der Kunde bereits überprüft?
Bevor ein Kunde erstmalig Tokens erhalten kann, muss er sich beim Emitten-
ten legitimieren lassen. Dies geschieht über eine Videolegitimation. War die
Legitimation erfolgreich, wird er vom Emittenten in eine Liste von verifizier-
ten Personen eingetragen.
262. Hat Emittent genug Tokens?
Hält der Emittent noch genügend Tokens, um sie dem Zahlenden übertragen
zu können?
3. Deckt die eingehende Zahlung die offene Rechnung?
Der Registerführer verbucht die Zahlungen gegen die offene Rechnung und
überprüft sie auf Vollständigkeit.
Wurden alle Bedingungen erfolgreich überprüft, erlaubt der Emittent dem Regis-
terführer, die gekauften Tokens der Kundenwalletadresse zuzuweisen.
Abb. 4.3: Zeichnungsablauf mit Ethereum Wallet
274.4 Erstellung eines neuen Produktes
Für jedes neue Produkt wird ein neuer Smart Contract erzeugt. Der Code für die-
sen Smart Contract ist in der Ethereum eigenen Sprache Solidity geschrieben. Der
Quellcode des Smart Contracts befindet sich in einem xpecto eigenen Git Reposito-
ry.
Die Erstellung des Smart Contracts nimmt folgenden Weg:
1. Die Client-Anwendung xpectoPro downloaded den Smart Contract vom
xpecto Git Repository. Dieser Code ist noch kein gültiger Solidity Code, da
im Konstruktor noch Platzhalter sind die nach dem Download durch Texter-
setzung ausgetauscht werden. Der Platzhalter tokenname kann beispielsweise
durch den Namen xpecto-Token“ersetzt werden.
”
// contract
constructor() public {
xpectoMandator = "{{mandator}}";
symbol = "{{tokensymbol}}";
name = "{{tokenname}}";
issuer = {{issuer}};
registrar = {{registrar}};
addToWhitelist(issuer, "issuer");
addToWhitelist(registrar, "registrar");
}
Listing 4.2: Platzhalter für Textersetzung des in doppelt geschweiften Klammern.
2. Damit der Smart Contract der Ethereum Blockchain übergeben werden kann,
muss er in Bytecode konvertiert werden und es muss ein Application Binary
Interface über den Smart Contract generiert werden. Beide Schritte werden
über den eigenen xpecto Ethereum Node durchgeführt.
3. Der Bytecode wird in die Blockchain geschrieben. Da Ethereum zwei Ar-
ten von Chains besitzt, das Mainnet und das Ropsten Testnet, muss ange-
geben werden, in welcher der beiden Instanzen geschrieben werden soll. Ei-
ne Übertragung in die Chain geschieht über einen Remote Procedure Call
Aufruf des xpecto eigenen Ethereum-Nodes. Da das Hochladen eines Smart
Contracts ebenfalls eine Transaktion in der Ethereum Blockchain ist, fallen
dabei Gebühren an. Diese Gebühren werden Gasprice genannt und können
frei gewählt werden. Umso höher der Gasprice einer Transaktion gewählt
wird, desto schneller wird sie von einem Miner in einem Block geschrieben.
Der Gasprice beim Hochladen eines Smart Contracts bei xpecto orientiert sich
28am durchschnittlich gezahlten Gasprice im Ethereum Netzwerk. Dieser wird
über den xpecto Ehtereum-Node ermittelt, um anschließend einen geeigneten
Gasprice zu wählen.
4. Bei einer erfolgreichen Transaktion wird dem hochgeladenen Smart Contract
eine Adresse zugeordnet. Unter dieser Adresse ist der Smart Contract in der
Ethereum Blockchain verfügbar und kann Beispielsweise über das Etherscan
Portal https://etherscan.io/ eingesehen werden.4.4
Abb. 4.4: Etherscan Smart Contract Übersicht
295 Implementierung Smart Contract
Der Implementierte Smart Contract orientiert sich an dem Ethereum Request for
Change (ERC)Ethereum Improvement Proposal (EIP)20 Standard. Dieser Standard
ist eine Schnittstellenbeschreibung für Tokensale Smart Contracts auf der Ethereum
Blockchain. Der Standard stellt eine Basisfunktionalität, wie Tokentransfer und die
Genehmigung von fremden Tokens (EIPs 2020, vgl.), bereit.
5.1 Überprüfungen
5.1.1 Ist der Funktionsaufrufer Issuer oder Emittent?
Bei dieser Überprüfung handelt es sich um einen Modifier. Hier wird überprüft,
ob der Methodenaufrufer der registrierte Registrar oder Emittent ist. Falls der
Methodenaufrufer weder Registrar noch Emittent ist, wird die Funktion, welche
diesen Modifier verwendet nicht aufgeführt.
modifier onlyIssuerOrRegistrar {
require(msg.sender == issuer || msg.sender == registrar, "only
,→ valid for issuer or registrar");
_;
}
5.1.2 Zeitstempel Überprüfung
Manchen Funktionen muss ein Zeitstempel übertragen werden. Dieser gibt an,
zu welchem Zeitpunkt die Funktion aufgerufen worden ist. Der Zeitpunkt muss
dabei lokal vom Client mitgeteilt werden, da es nicht möglich ist, den aktuellen
Zeitpunkt über die EVM zu erfahren. Um zu verhindern, dass der mitgeteilte
Zeitpunkt in der Zukunft liegt, wird überprüft, ob der Zeitpunkt älter ist als der
Erzeugungszeitpunkt des Blocks, in dem die Mintingoperation durchgeführt wird.
require(5.1.3 Authentifizierung
Für manche Funktionen muss zuerst überprüft werden, ob die verwendeten Wallet-
Adressen zugelassen sind. Dies wird über eine Whitelist gelöst, die im Abschnitt
5.5 genauer erläutert wird.
require(isWhitelisted(), " needs
,→ to be whitelisted by registrar or issuer");
5.1.4 Pausierung des Smart Contracts
Wurde eine Instanz des Smart Contracts erzeugt, ist er zu Beginn immer pausiert.
In dieser Zeit können manche Funktionen nicht ausgeführt werden. Daher wird vor
Ausführung einer solchen Funktion erst der Status des Smart Contracts abgefragt.
require(!paused, "public transfer is paused");
5.1.5 Bestandsüberprüfung bei Token- Übertragungen
Der zu übertragene Betrag darf den Bestand des Senders nicht überschreiten.
require(_value5.2 Konstruktor
Im Konstruktor wird dem Smart Contract der Mandator, das Tokensymbol, der
Tokenname, die Walletadresse des Emittenten und des Registrars mitgeteilt.
Die Argumente werden dem Smart Contract nicht über die Konstruktorargumente
mitgeteilt, da der geschriebene Quellcode bereits in einem Repository liegt. Darum
wird der Quellcode des Smart Contracts, zur Erstellung eines Produktes, von dem
xpecto/talonec Repository heruntergeladen und die Argumente für den Smart Con-
tract über eine Textersetzung eingefügt. Sobald die Walletadressen des Emittenten
und des Registrars bekannt sind, werden sie der Whitelist hinzugefügt. Siehe Ab-
schnitt 5.5.
// contract
constructor()
public {
xpectoMandator = "{{mandator}}";
symbol = "{{tokensymbol}}";
name = "{{tokenname}}";
issuer = {{issuer}};
registrar = {{registrar}};
addToWhitelist(issuer, "issuer");
addToWhitelist(registrar, "registrar");
}
32Sie können auch lesen
