To Author's Page
Teil 3: Konsens-Mechanismen
Im ersten Teil dieser Beitragsreihe wurde dargestellt, dass die Blockchain eine kryptografisch verbundene Kette von in Zeitintervallen erstellten Blöcken ist, die diejenigen Transaktionen aus dem jeweiligen Intervall enthalten, die von den Teilnehmern als ausgeführt akzeptiert werden. Sie sind damit unveränderlicher Bestandteil des Ledgers über dessen Kopie die Teilnehmer verfügen. Die verbleibende Frage ist nun, auf welche Weise die Teilnehmer eines Blockchain-Systems einen Konsens über den jeweils aufzunehmenden Block finden. Der Vorgang zum Finden eines solchen Konsenses wird in diesem Zusammenhang auch als Konsens-Mechanismus bezeichnet. Im zweiten Teil dieser Reihe wurden verschiedene Varianten von Blockchain-Ansätzen vorgestellt. Unterschieden wurde in die Dimensionen öffentlich/privat und permissionless/permissioned. Je nach Kombination bestehen auch Auswirkungen auf die Anforderungen hinsichtlich der Konsensmechanismen. In einer privaten Blockchain, bei der alle Teilnehmer untereinander bekannt sind, muss ein Konsensmechanismus nicht die gleiche Komplexität aufweisen, wie in einem System, in dem die Teilnehmer anonym sind und damit nicht klar ist, wem man vertrauen kann und wem nicht [1]. Entsprechend sind im Zuge der Entwicklung der Blockchain-Technologien unterschiedliche Konsensmechanismen entwickelt worden, deren Variantenreichtum beständig zunimmt. In diesem Beitrag soll ein Überblick über die derzeit relevanten Konsens-Mechanismen gegeben werden. Hervorgehoben werden sollen dabei die Mechanismen von Bitcoin und von Ripple.
Mit Bitcoin, das die Blockchain-Technologie populär gemacht hat, wurde der sog. “Proof of Work”-Algorithmus (PoW) entwickelt. Da es sich bei Bitcoin um eine öffentliche und permissionless Blockchain mit sich gegenseitig nicht bekannten Teilnehmern handelt, bestehen hohe Anforderungen an die Sicherheit und Funktionsfähigkeit des Algorithmus. Prinzipiell kann jeder Teilnehmer im Bitcoin-Netzwerk an der Blockerzeugung mitwirken. Das PoW-Konzept ist dabei so konstruiert, dass ungefähr alle 10 Minuten irgendein Teilnehmer des Systems die in dieser Zeit bei ihm angelangten Transaktionen zu einem nicht mehr veränderbaren Block zusammenfasst (vgl. Abbildung 1) [2]. Dieser wird dann an alle verteilt und ist schließlich Teil der kollektiven Blockchain. Der Empfänger einer Transaktion muss also so lange warten, bis er einen Block bekommt, der die Transaktion enthält. Dann ist sie beglaubigt.
Abbildung 1: Blockerstellung bei Bitcoin (Mining)
Um die Teilnehmer des Bitcoin-Systems zum Erzeugen der Blöcke zu bewegen, wird für jeden Block, der Bestandteil der Blockchain wird, eine Belohnung in Form einer festgelegten Anzahl an Bitcoins gewährt. Diese Bitcoins werden zu genau diesem Zeitpunkt erschaffen. Das Erzeugen eines Blocks wird daher auch als Mining bezeichnet. Derjenige, der zuerst einen Block erzeugt, bekommt als Einziger die Belohnung. Zusätzlich erhält der Miner die in den Transaktionen enthaltenen Transaktionsgebühren. Aufgrund der Belohnung besteht ein Anreiz, an der Blockerzeugung mitzuwirken. Damit gesichert ist, dass nur ungefähr alle 10 Minuten ein Block erzeugt wird, muss die Software des Miners neben der Überprüfung der Transaktionen noch eine Rechenaufgabe lösen. Diese passt sich im Schwierigkeitsgrad automatisch an die am Mining beteiligte Rechenleistung an. Je mehr Teilnehmer also an dem Mining teilnehmen bzw. je stärker deren Rechenleistung ist, desto schwieriger wird die Aufgabe. Die Wahrscheinlichkeit, einen Block zu erzeugen, entspricht dabei dem Anteil an der gesamten Rechenleistung des Bitcoin-Netzwerks [3]. Bedingt durch das verteilte Arbeiten an der Blockerzeugung und dem notwendigen Zeitbedarf für die Aktualisierung der Blockchain bei den Teilnehmern mit einem neuen Block kann es vorkommen, dass zwei oder mehrere Miner gleichzeitig Blöcke erzeugen und diese in das Netz stellen. Da diese in unterschiedliche Reihenfolgen bei den einzelnen Teilnehmern ankommen und von diesen immer nur der erste Block akzeptiert wird, kann die Blockchain somit temporär in Verzweigungen zerfallen. Um dies zu korrigieren, sieht der PoW-Algorithmus vor, dass das Mining immer am längsten Zweig der Blockchain fortgesetzt wird [1]. Damit stabilisiert sich die Blockchain von selbst. Um sicherzustellen, dass nur der Miner die Belohnung erhält, dessen Block sich durchgesetzt hat, wird die Auszahlung vom System entsprechend verzögert. Aufgrund seiner Konstruktion hat sich der PoW-Ansatz von Bitcoin bis heute trotz zahlreicher Angriffe als funktionsfähiges Konzept erwiesen. Die Mehrzahl der Transaktionen in der Blockchain haben noch Bitcoins zum Gegenstand, jedoch ist das Transaktionsbuch offen konstruiert, d.h. prinzipiell können auch andere Assets (bzw. deren digitale Repräsentanten) über die Bitcoin-Blockchain transferiert bzw. verwaltet werden. Dies nutzen bereits viele Blockchain-basierte Dienste. Zudem können Regeln in der Blockchain von Bitcoin angelegt werden, womit sich (unter Beschränkungen) auch Smart Contracts realisieren lassen. Allerdings weist das Bitcoin-Konzept auch einige Problembereiche auf, die es für eine umfassendere Nutzung sowie für bestimmte Anwendungsbereiche nur bedingt brauchbar machen. Einige dieser Problembereiche sind dabei zumindest von der technischen Seite durch Anpassungen leicht zu beheben. Dazu gehört beispielsweise die limitierte Blockgröße, die bei der derzeitigen Konfiguration nur ca. 600.000 Transaktionen pro Tag ermöglicht. Andere Problembereiche sind dagegen systemimmanent und somit nur schwer bis gar nicht zu lösen. So kann jeder Miner frei entscheiden, welche Transaktionen er in den Block aufnimmt. Damit besteht die Gefahr, dass Transaktionen aus ideologischen, politischen oder sonstigen Gründen abgelehnt werden und ggfs. einen längeren Zeitraum benötigen, um von einem anderen Miner in die Blockchain aufgenommen zu werden [4]. Desweiteren schützt der PoW-Algorithmus nur so lange vor Manipulationen, wie sich die Mining-Leistung über viele Teilnehmer verteilt. Verfügt ein Miner über einen längeren Zeitraum über mindestens 51% der Mining-Leistung, so kann er die Blockchain (auch rückwirkend) manipulieren. Aufgrund der finanziellen Anreize hat sich die Mining-Leistung in den letzten Jahren durch die Nutzung spezieller Hardware und den Zusammenschluss von Minern zu sog. Mining-Pools stark erhöht und gleichzeitig konzentriert, so dass eine entsprechende Gefährdung gegeben ist. Auch aus ökologischer Sicht ist das Bitcoin-Netzwerk bedenklich. Anfang Januar 2016 wurden pro Sekunde im Bitcoin-System über 900 Billiarden Berechnungen zur Bewältigung der Rechenaufgabe vorgenommen [5]. Für die Erzeugung eines Blocks werden ca. 6000 Sekunden (10 Minuten) benötigt. Nach Schätzungen des Magazins Mainboard ergibt sich ein durchschnittlicher Tages-Stromverbrauch von 1,57 Haushalten pro Bitcoin-Transaktion bzw. der 5.033-fache Stromverbrauch im Vergleich zu einer Transaktion von Visa [6]. Aufgrund der günstigen Preise für Elektrizität werden die großen Mining-Pools derzeit in China in der Inneren Mongolei betrieben. Alternativ zur direkten Nutzung der Bitcoin-Blockchain verwenden einige Anbieter von Blockchain-Technologien einen PoW-Algorithmus in ihren eigenen Produkten. Zur Bewältigung der oben genannten Problembereiche werden dabei in der Regel Variationen gegenüber dem Ansatz von Bitcoin vorgenommen. Ein Beispiel dafür ist die Einführ
ung einer sog. Mining-Diversity, die die Anzahl der Blöcke, die ein Teilnehmer innerhalb eines gegebenen Zeitintervalls erzeugen kann, beschränkt [4].
Zudem wurden alternative “Proof of”-Mechanismen entwickelt, insbesondere um die Blockerzeugung unabhängig von der Rechenleistung zu machen und zu kürzeren Blockerzeugungszyklen zu gelangen. Einen Überblick geben [7] und [8]. Eine viel diskutierte Alternative ist der “Proof of Stake”-Ansatz (PoS). Hier hängt die Wahrscheinlichkeit für die Erzeugung eines Blocks durch einen Teilnehmer von dessen wertmäßigem Anteil am Netzwerk ab, d.h. dem Anteil seines Vermögens in der jeweiligen virtuellen Währung am Gesamtvermögen. Untersuchungen zeigen jedoch, dass mit diesem Ansatz im Vergleich zu PoW andere und zum Teil gravierende Problembereiche hinsichtlich der Sicherheit der Blockchain einhergehen [3]. Aus diesem Grund finden auch hier Weiterentwicklungen statt, wie z.B. der “Delegated Proof of Stake”-Ansatz, bei dem aus den Teilnehmern häufig wechselnde Teilmengen bestimmt werden, denen dann die Blockerzeugung gestattet ist. Andere Ansätze kombinieren PoS und PoW zu hybriden Konzepten, so dass beispielsweise das System primär über einen PoS-Ansatz funktioniert, Zusammenfassungen dieser primären Blockchain jedoch in regelmäßigen Abständen in der Bitcoin-Blockchain zwecks zusätzlicher Absicherung der Transaktionen gegenüber Manipulationen gespeichert werden, auch Blockchain Anchoring genannt.
Die bislang dargestellten Konsensmechanismen basieren darauf, dass ein Teilnehmer einen neuen Block erzeugt und dieser dann im Netz verteilt wird. Bis zur vollständigen Synchronisation des Netzes entsteht damit ein Zeitbedarf, der die Zeitdauer der Blockerzeugung plus die der vollständigen Verteilung umfasst. Einen völlig anderen Weg gehen die Konsensmechanismen, die Anbieter wie Ripple und Hyperledger verwenden. Es handelt sich hierbei um iterative Ansätze, bei denen sich die Knoten gemeinsam und zeitgleich auf den nächsten Block einigen. Die Funktionsweise soll stellvertretend für den Ripple Protocol Consensus Algorithm (RPCA) dargestellt werden [9]. Wie in allen Blockchain-basierten Netzen nehmen auch bei Ripple Knoten Transaktionen entgegen, überprüfen sie auf Korrektheit und verteilen sie im Netz [10]. Alle noch nicht im Ledger aufgenommenen Transaktionen werden bei Ripple als Kandidaten bezeichnet. Da die Verteilung der Transaktionen im Netz Zeit benötigt und die Transaktionen von unterschiedlichen Knoten eingebracht werden, haben die einzelnen Knoten in der Regel unterschiedliche Bündel an Kandidaten, auch als Candidate Set bezeichnet (siehe ① in Abbildung 2). Das Ziel des Konsensalgorithmus besteht nun darin, sich auf die gemeinsame Teilmenge der Kandidaten zu einigen, die dann dem Ledger hinzugefügt wird. Dies geschieht asynchron und iterativ über mehrere Runden. Die Knoten müssen sich dabei nicht vertrauen, es wird lediglich angenommen, dass es keine umfangreichen konspirativen Kollaborationen gibt.
Abbildung 2: Der Ripple Protocol Consensus Algorithm
Quelle: http://youtu.be/17RtYvWb60o
Jeder am Konsensprozess beteiligte Knoten verfügt über eine Liste von aktiven Knoten, die sog. Unique Node List (UNL) ②. Mit diesen Knoten werden sog. Proposals ausgetauscht, die Vorschläge über aufzunehmende Transaktionen enthalten. Zu Beginn schickt ein Knoten zunächst sein Candidate Set als Proposal an die aktiven Knoten in seiner UNL und erhält im Gegenzug die Proposals der anderen Knoten. Die in den fremden Proposals enthaltenen Transaktionen werden nun mit denen im eigenen Candidate Set verglichen ③. Alle Transaktionen im Candidate Set, die in mindestens 50% der Proposals vorgekommen sind, werden nun zu einem neuen Proposal gepackt und an alle aktiven Knoten gesendet ④. Der Schwellenwert wird nun auf 60% erhöht und die Auszählung mit den neu eingehenden Proposals erneut vorgenommen. Alle Transaktionen mit mindestens 60% werden nun erneut als Proposal verpackt und versendet. Der Schwellenwert wird in der nächsten Runde auf 70% und in der finalen Runde schließlich auf 80% erhöht. Konsens besteht im RPCA hinsichtlich der Transaktionen in den Candidate Sets, die mindestens 80% erreichen. Diese werden nun von jedem Knoten zur Erzeugung des neuen Blocks verwendet ⑤. Um sicherzugehen, dass jeder Knoten auch tatsächlich den gleichen Block erzeugt hat, werden schließlich noch deren digitalen Fingerabdrücke untereinander ausgetauscht. Der Zeitbedarf für den gesamten Konsensprozess liegt bei wenigen Sekunden, was vor allem aus praktischer Sicht vorteilhaft ist. Transaktionen, die nicht aufgenommen wurden, verbleiben im Candidate Set und gehen mit den zwischenzeitlich neu hinzugekommenen in den nächsten Konsensprozess ein.
Die Darstellungen in diesem Beitrag haben gezeigt, dass bereits einige Konsensmechanismen existieren, die in der Praxis einsatzfähig sind. Aufgrund ihrer unterschiedlichen Konstruktionen eignen sie sich dabei auch in unterschiedlicher Weise in Abhängigkeit von ihrem Einsatzbereich. So ist es z.B. fraglich, ob in einem privaten und permissioned Blockchain-System ein aufwändiger PoW-Ansatz nötig ist, da die am Konsensprozess beteiligten Knoten bekannt sind. Da es sich bei den Konsens-Mechanismen um system- und funktionskritische Bestandteile bei Blockchain-Systemen handelt, können hier für die Zukunft noch weitere Entwicklungen erwartet werden, um die unterschiedlichen Bedürfnisse der Praxis abzudecken.
[1]Swanson, T. (2015): Consensus-as-a-service: a brief report on the emergence of permissioned, distributed ledger systems, http://www.ofnumbers.com/wp-content/uploads/2015/04/Permissioned-distributed-ledgers.pdf [2]Cap, C. H. (2012): Bitcoin – das Open-Source-Geld, in: HMD Praxis der Wirtschaftsinformatik, Heft 283, 49. Jahrgang, S. 84-93. [3]BitFury Group (2015b): Proof of Stake vs. Proof of Work, http://bitfury.com/white-papers-research. [4]Greenspan, G. (2015): MultiChain Private Blockchain, http://www.multichain.com/white-paper. [5]Blockchain.info (2016): Hash Rate, http://blockchain.info/de/charts/hash-rate. [6]Malmo, C. (2015): Bitcoin hat ein großes Problem: Die Krypto-Währung ist einfach nicht nachhaltig, http://motherboard.vice.com/de/read/das-oeko-problem-von-bitcoin-darum-ist-die-krypto-waehrung-nicht-nachhaltig-3920. [7]Patterson, R. (2015): Alternatives for Proof of Work, Part 1: Proof Of Stake, http://bytecoin.org/blog/proof-of-stake-proof-of-work-comparison. [8]Patterson, R. (2015): Alternatives for Proof of Work, Part 2: Proof of Activity, Proof of Burn, Proof of Capacity, and Byzantine Generals, http://bytecoin.org/blog/proof-of-activity-proof-of-burn-proof-of-capacity. [9]Schwartz, D.; Youngs, N.; Britto, A. (2014): The Ripple Protocol Consensus Algorithm, http://ripple.com/files/ripple_consensus_whitepaper.pdf [10]Cohen, D.; Schwartz, D.; Britto, A. (2015): The Ripple Ledger Consensus Process, http://ripple.com/knowledge_center/the-ripple-ledger-consensus-process.
Frankfurt School gGmbH
Adickesallee 32-34
60322 Frankfurt am Main
