Im Laufe der Zeit entwickelten sich verschiedene Ausprägungen der DLT, die sich anhand verschiedener Dimensionen unterscheiden lassen. Allen gemein ist die gemeinschaftliche Ver-waltung von Daten und deren Veränderung durch darauf angewandte Operationen. Im Fol-genden werden einige dieser Dimensionen, die wesentliche Eigenschaften eines DLT-tems ausmachen, aufgezeigt. Ein wichtiger Bestandteil bei der Entwicklung eines neuen Sys-tems besteht darin, für jede dieser Dimensionen eine Wahl zu treffen.
2.3.1 Anwendung und Flexibilität
Die Ausgestaltung der auf einem DLT-System basierenden Anwendung definiert einerseits das gemeinsam zu verwaltende Datenmodell und andererseits die darauf anwendbaren Ope-rationen. Man kann die Anwendung sehr eng fassen oder sehr flexibel. Grundsätzlich bedingt eine eng gefasste Anwendung bessere Optimierbarkeit und eine flexible Anwendung höhere Kosten (schwierigeres Protokoll, weniger Vorhersehbarkeit, grössere Angriffsfläche, etc.).
Bei Bitcoin handelt es sich um eine sehr eng gefasste Anwendung. Der verwaltete Datensatz ist eine Menge von Transaktionen und daraus resultierenden Salden (Token), die bestimmten Adressen zugeordnet sind. Die darauf angewandten Operationen sind Transaktionen, die To-ken neuen Adressen zuweisen. Dabei können Operationen nur auf ToTo-ken und deren Metada-ten zugreifen, die von der Transaktion verändert werden. Es ist nicht möglich, beliebig auf die Daten zuzugreifen, sondern die Transaktionen agieren voneinander isoliert.
Ethereum ist ein Gegenbeispiel einer sehr flexiblen Anwendung. Die Operationen sind in einer mächtigeren Sprache (Turing-vollständig) beschrieben, die auch auf von vorherigen Operatio-nen geschriebene Daten zugreifen kann. Dadurch wird es möglich, beliebige Daten in der Blockchain abzulegen und später zu verändern. Diese Flexibilität bedeutet aber auch, dass wesentlich schlechter optimiert werden kann: so kann zum Beispiel der Rechenaufwand zur Ausführung einer Operation nicht abgeschätzt werden (Halting Problem).
Zwischen den beiden Extremen Bitcoin und Ethereum existieren zahlreiche Varianten. So kön-nen zum Beispiel die eigentliche Ausführung der Operatiokön-nen ausgelagert werden und nur die Endwerte mit einem Ausführungsbeweis von den Nodes verarbeitet werden. Dies ist insbe-sondere bei sogenannten Zero Knowledge-Systemen der Fall, bei denen die Teilnehmer nur die Datenveränderung sehen, nicht aber die ausgeführten Operationen.
Neben reinen Daten kann man in Blockchains auch Programmcode ablegen, der durch Ope-rationen angestossen wird und sodann vorbestimmte Berechnungen ausführt. Diese Pro-gramme werden auch Smart Contracts genannt. Verschiedene Personen können durch einen Smart Contract miteinander interagieren, ohne sich untereinander zu vertrauen. Der Smart Contract kann also die Rolle eines zentralen Mediators übernehmen.
Eine Decentralized Autonomous Organization (DAO) ist ein Beispiel eines Smart Contracts, bei dem der Smart Contract selbständig über die Mittel einer Organisation verfügen kann. Da-bei ist die Gouvernanz der Organisation im Smart Contract beschrieben und es ist damit ga-rantiert, dass sich die Organisation wie beschrieben verhält. Im 2016 wurde mit «The DAO»
24/170
ein Investment-Fund mit dem Ziel geschaffen diesen gemeinschaftlich zu steuern. Der Soft-ware-Code von «The DAO» hatte allerdings einen Fehler, der es einem Angreifer ermöglichte Gelder im Wert von 50 Millionen USD zu entwenden.23
Eine andere Form von Smart Contract sind DApps (Decentralized Applications, also ein Spiel, eine Handelsbörse, oder Ähnliches), die ganz oder teilweise auf der Blockchain ausgeführt werden. Bei all diesen Beispielen besteht der Mehrwert darin, dass das Verhalten von vornhe-rein festgelegt ist und alle Teilnehmer, die mit dem Smart Contract interagieren, sich auch darauf verlassen können, dass sich der Smart Contract korrekt verhält.
In der Bitcoin-Blockchain kann nicht nur der Transfer von Bitcoins, sondern auch der Transfer weiterer Daten registriert werden. Dazu wird das Bitcoin-Protokoll um ein anwendungsspezi-fisch programmiertes Protokoll ergänzt. Die Blockchain dient als Grundlage und Garant für die Sicherheit der Anwendung. Das angehängte Protokoll ermöglicht es, dem Bitcoin im Rahmen einer Transaktion zusätzliche Metadaten anzuhängen, z. B. die Information «Wertpapier X», und diese in der Blockchain zu speichern. Die angehängte Information ist zu vergleichen mit einer «Färbung» der Bitcoin, weshalb solche Anwendungen oft auch als Colored Coin-Modelle bezeichnet werden. Indem sich Metadaten mit Bezug auf Vermögenswerte, wie z. B. Wertpa-piere, durch eine Blockchain-Transaktion technisch von einer Person zur anderen übertragen lassen, kann das Modell genutzt werden, um die Zugehörigkeit von Vermögenswerten in der Blockchain zu registrieren, ohne dass für diesen Zweck ein Zentralregister bestehen muss.
Ein wichtiger Unterschied zu Bitcoin ist in diesem Modell jedoch der Bezug zu einem externen Vermögenswert.
2.3.2 Zugang
Im Zusammenhang mit DLT spricht man häufig von Permissioned oder Permissionless DLT-Systemen (siehe Tabelle 1).
Permissioned DLT-Systeme haben einen eingeschränkten Zugang, und werden in erster Linie von Konsortien betrieben. Die Teilnehmer kennen einander und die Anzahl Teilnehmer im System ist bekannt.
Unter Permissionless DLT-Systemen versteht man Systeme, bei denen die Teilnehmer jeder-zeit beitreten beziehungsweise austreten können und keine zentrale Instanz Zugang erteilt.
Damit ist in einem solchen System nicht klar, wie viele Teilnehmer zu einem bestimmten Zeit-punkt im System sind. Folglich sind klassische, auf Abstimmungen basierte, Konsensalgorith-men nicht anwendbar, da die für eine Mehrheit benötigte Anzahl StimKonsensalgorith-men unbekannt ist.
Die Begriffe Permissioned und Permissionless können sich auch beziehen auf die Schreib-rechte im System, d.h. welche Teilnehmer Operationen bestätigen können. Zudem muss spe-zifiziert werden, wer Lesezugriff auf die Daten hat. Bei einem Permissionless DLT-System hat grundsätzlich jeder Teilnehmer Lesezugriff, da er auch beim Konsens mitmachen kann und der Lesezugriff dafür Voraussetzung ist. Bei einem Permissioned DLT-System hingegen kön-nen die Daten öffentlich zugänglich sein, oder nur bestimmten Auditoren und den Konsensteil-nehmern (in diesem Fall Validierer).
23 Für Einzelheiten zu DAOs, vgl. Ausführungen unter Ziff. 6.7.2.6.
25/170
Tabelle 1: Systeme mit unterschiedlichem Zentralisierungsgrad (Quelle: CPMI 2017: 8) Beschreibung Bestehende
Sys-teme der zentralen Finanzmarktinfra-struktur
Nur zugelassene Teilneh-mer können die Dienstleis-tung nutzen. Rollen sind differenziert.
Alle haben Zugang zum System und kön-nen alle Rollen ein-nehmen.
Validierung Zentrale Validierung
Dezentrale Validierung
Zugang Eingeschränkt Nicht eingeschränkt
Rollen der Teil-nehmer
Differenziert Nicht differenziert Beispiel Zahlungssystem
SIC
Corda, USC Bitcoin, Ethereum
2.3.3 Konsensmechanismus
Allen DLT-Systemen gemein ist die Tatsache, dass sich eine Menge von Teilnehmern, die sich gegenseitig nur beschränkt vertrauen, über den aktuellen Zustand des Systems einigen müs-sen. Es gibt eine Vielzahl von Möglichkeiten, diesen Konsens zu erreichen. Dabei erstellen Konsensalgorithmen eine gemeinsame Abfolge der Operationen, aus der sich deren Gültigkeit und ein gemeinsamer Endzustand ergeben.
Bei Permissioned DLT-Systemen, also Systemen mit Zugangskontrolle, ist es möglich, klassi-sche Konsens-Algorithmen aus dem Bereich des Verteilten Rechnens zu verwenden wie zum Beispiel Paxos oder Practical Byzantine Fault Tolerance (PBFT). Diese Protokolle basieren auf Abstimmungen, bei denen die Teilnehmer über die nächste anzuwendende Operation ab-stimmen. Dies ist möglich, da jeder Teilnehmer weiss, wie viele Stimmen eine Mehrheit erge-ben und wann die Abstimmung erfolgreich ist.
In Permissionless DLT-Systemen, die keine Zugangskontrolle haben, ist diese Art der Abstim-mung nicht möglich, da sich jeder Teilnehmer als beliebig viele unabhängige Teilnehmer aus-geben kann (Sybill-Attacke) und eine Abstimmung nie abgeschlossen werden kann. Deshalb benötigen diese Systeme einen Mechanismus, der es für die Teilnehmer unattraktiv macht, gegen das System zu arbeiten. Hierzu wird zufällig ein Teilnehmer ausgewählt, der die nächste anzuwendende Operation vorschlägt. Die anderen Teilnehmer können diesen Vorschlag an-nehmen, indem sie darauf aufbauen, sollten sie als nächstes ausgewählt werden. Dabei wer-den einzelne Operationen in Blöcke gruppiert, um die Effizienz des Systems zu steigern.
Bitcoin verwendet zu diesem Zweck den Proof-of-Work-Mechanismus, bei dem solange kryp-tographische Funktionen ausgeführt werden bis das Resultat gewisse Eigenschaften auf-weist.24 In einem Proof-of-Work-System hängt die Wahrscheinlichkeit, dass ein Teilnehmer den nächsten gültigen Block findet, allein von dessen Rechenleistung ab. Die spezialisierten Miner unterhalten deshalb grosse Rechenleistungskapazitäten, was zu einem grossen Ener-gieverbrauch der Proof-of-Work-Systeme führt. Für einen Miner ist es dabei solange ökono-misch sinnvoll diese Rechenleistung zu betreiben, wie die Kosten dafür tiefer sind als das erwartete Einkommen aus erfolgreich validierten Blöcken.
24 Vgl. Ziff. 2.2.
26/170
Alternativ zum Proof-of-Work gibt es beispielsweise die Möglichkeit, einen zufälligen Teilneh-mer anhand der Daten im System zu wählen. Zum Beispiel kann man bei kryptobasierten Ver-mögenswerten einen (pseudo-)zufälligen Token auswählen, dessen zugeordnete Adresse (Stakeholder) den nächsten Vorschlag für die Weiterentwicklung der Blockchain machen darf.
In einem solchen Proof-of-Stake-System steigt die Wahrscheinlichkeit, den nächsten Vor-schlag machen zu dürfen, mit den Token eines Teilnehmers an. Dadurch entfällt das aufwän-dige Rechnen von Proof-of-Work und die Teilnehmer mit einem höheren Interesse am Fortbe-stehen des Systems (da sie darin investiert haben) treffen relativ häufig Entscheidungen. Al-lerdings ist die Umsetzung dieses Konzepts nicht einfach, da es Teilnehmern möglich ist, sich strategisch zu verhalten und so ihren Einfluss im System zu vergrössern oder sich inkorrekt zu verhalten. Die meisten Proof-of-Stake-Systeme verwenden daher bislang eine Kombination aus Proof-of-Stake und Proof-of-Work um diese Manipulationsversuche zu lösen, haben aber dementsprechend den hohen Energieverbrauch als Nachteil.
2.3.4 Log-Struktur
Die Folge aller in einem System angewandten Operationen wird auch Log genannt. Bei Block-chains werden die Operationen in Blöcken gruppiert und in eine lineare Liste (Chain) einge-ordnet. Neben einer solchen linearen Liste ist es aber auch möglich, andere Strukturen für den Log zu verwenden, sofern immer eindeutig ist, in welcher Reihenfolge Operationen auszufüh-ren sind, die potenziell im Widerspruch zueinander stehen. Zum Beispiel erstellt ein Tangle eine partielle Ordnung. Dabei bestätigen Transaktionen jeweils zusätzlich frühere Transaktio-nen, wodurch die betroffenen Transaktionen untereinander geordnet werden. Auch Mischfor-men sind möglich: so hat Ethereum zwar eine lineare Blockchain, kann aber natürlich entste-hende Abzweigungen, sogenannte Uncle Blocks, wieder zusammenführen.
Bei Permissioned DLTs kann auf den Log verzichtet werden, da man den Teilnehmern, die Operationen ordnen, komplett vertraut. Dabei rechnet ein neu beitretender Teilnehmer nicht wie bei Permissionless DLTs alle Operationen vom Ausgangszustand nach, sondern über-nimmt den aktuellen Zustand von einem existierenden Teilnehmer und baut darauf auf.
2.3.5 Anonymität und Privatsphäre Pseudonymität bei Bitcoin
Bei Bitcoin braucht ein Akteur zwar nicht seinen richtigen Namen zu verwenden, jedoch dienen seine Adressen als Identität innerhalb des Systems. Diese Zwischenform wird oft als Pseudo-nymität bezeichnet.25
Ein Nutzer kann mit seinem Verhalten seine Anonymität bis zu einem gewissen Grad selber steuern. Er kann beliebig oft neue Adressen erstellen. Dies kann die Anonymität aber nur dann erhöhen, wenn vom selben Nutzer erstellte Adressen nicht miteinander in Verbindung ge-bracht werden können. Sobald Transaktionen getätigt werden, steigt aber die Wahrscheinlich-keit, Muster und Verbindungen zwischen den von einem einzelnen Nutzer kontrollierten Ad-ressen zu erkennen.
Weitere Möglichkeiten, um die Anonymität zu erhöhen, sind sogenannte Mixers und bestimmte Wallet Anbieter. Bei einem Mixer können Nutzer Token zusammen mit der Information über den gewünschten Empfänger an die Adresse des Mixers schicken. Der Mixer schickt dann von dieser Adresse aus (andere) Token an die vom Nutzer spezifizierte Adresse. Eine ähnliche Vermischung von Token kann auch über Wallet Anbieter erreicht werden, die die Token aller
25 Vgl. Ziff. 2.2.
27/170
Nutzer in einem Pool zusammenfassen. Sowohl bei einem Mixer wie auch bei einem entspre-chenden Wallet wird die Anonymität nur dann erhöht, wenn diese keine Informationen über die Nutzer erfassen.
Grundsätzlich ist es für Bitcoin-Nutzer schwierig, vollständige Anonymität zu erreichen, da jede Bitcoin-Transaktion erfasst und gespeichert wird und mit zunehmender Transaktionshistorie Muster und Verbindungen erkennbar werden.
Anonymität bei anderen kryptobasierten Systemen
Sowohl Unternehmen wie auch Privatpersonen können ein Interesse daran haben, dass nicht alle ihre Daten in einer offenen Blockchain von Nachbarn, Mitarbeitern, Geschäftskonkurren-ten etc. eingesehen werden können. Es haben sich deshalb Entwickler verschiedener krypto-basierter Systemen zum Ziel gesetzt, die Anonymität ihrer Nutzer im Vergleich zu Bitcoin zu erhöhen. Dazu stehen verschiedene technologische Möglichkeiten zur Verfügung, die bei-spielsweise versuchen, die Verfolgbarkeit von Transaktionen zu verschleiern (z.B. Monero) oder diese zu unterbrechen (z.B. Zerocoin).
2.3.6 Skalierung
Sämtliche Teilnehmer in der Bitcoin- und vielen anderen Blockchains speichern heute eine grosse Menge an Daten (nämlich die gesamte Transaktionshistorie) und verarbeiten jede ein-zelne Transaktion. Dies führt zu einer hohen Resilienz des Systems, beeinträchtigt aber des-sen Skalierbarkeit. Dieses Problem wird von Softwareentwicklern adressiert, indem die Daten-menge und Operationen in Gruppen geteilt (Sharding) oder indem die Last im Netzwerk durch Aggregieren von vielen kleinen Operationen reduziert (Off-Chain-Protokolle) werden.
Beim Sharding werden die Teilnehmer, die Daten und die Operationen in Gruppen (Shards) eingeteilt. Teilnehmer innerhalb einer Gruppe verarbeiten nur Transaktionen innerhalb dieser Gruppe und müssen entsprechend weniger Daten speichern und weniger Operationen verar-beiten. Teilnehmer validieren nicht mehr alle Operationen im System, sondern Gruppenteil-nehmer validieren lediglich gruppenspezifische Operationen. Damit erhöht sich die Rate der ausführbaren Operationen linear mit der Anzahl Shards. Allerdings erhöht sich auch der Auf-wand bei einer gruppenübergreifenden Operation, was mit steigender Anzahl der Gruppen häufiger geschieht. Ein Beispiel von Sharding ist das Plasma-Protokoll, mit dem die Ethereum-Blockchain in mehrere kleine, voneinander unabhängige, Ethereum-Blockchains unterteilt und somit die Last verteilt werden kann.
Off-chain-Protokolle, wie etwa das Lightning-Netzwerk bei Bitcoin oder State Channels bei Ethereum, aggregieren eine Menge von Off-Chain-Operationen, die zwischen einer kleinen Gruppe verhandelt wurden, in wenige On-Chain-Operationen. Zum Beispiel eröffnen beim Lightning-Netzwerk zwei Endpunkte einen Zahlungskanal über ein bestimmtes Guthaben. Die-ses Guthaben kann danach beliebig häufig den Besitzer wechseln, und erst am Ende des Kanals werden die Guthaben den Endpunkten durch eine Blockchain Transaktion ausbezahlt.
Dadurch werden die On-Chain-Kosten über beliebig viele Off-Chain-Transaktionen verteilt.
Während On-chain-Transaktionen zeitintensiv sein können, da sie zu ihrer Gültigkeit Bestäti-gungen durch die Blockchain-Teilnehmer voraussetzen, können Off-chain-Transaktionen grundsätzlich umgehend vorgenommen werden, wobei grundsätzlich keine auf der Blockchain stattfindenden Validierungen stattfinden. Die Parameter für die Gültigkeit einer Off-chain-Transaktion werden stattdessen in den Regelwerken bzw. technischen Standards des Off-chain Systems formuliert oder von Betreibern solcher Systeme autonom festgelegt
28/170