{"id":5102,"date":"2016-03-15T10:30:09","date_gmt":"2016-03-15T09:30:09","guid":{"rendered":"http:\/\/blog.frankfurt-school.de\/?p=5102"},"modified":"2023-10-05T12:11:06","modified_gmt":"2023-10-05T11:11:06","slug":"blockchain-technologien-konsens-mechanismen","status":"publish","type":"post","link":"https:\/\/blog.frankfurt-school.de\/de\/blockchain-technologien-konsens-mechanismen\/","title":{"rendered":"Blockchain-Technologien und ihre Implikationen"},"content":{"rendered":"

Teil 3: Konsens-Mechanismen<\/strong><\/p>\n

Einleitung<\/strong><\/h2>\n

Im ersten Teil dieser Beitragsreihe<\/a> wurde dargestellt, dass die Blockchain eine kryptografisch verbundene Kette von in Zeitintervallen erstellten Bl\u00f6cken ist, die diejenigen Transaktionen aus dem jeweiligen Intervall enthalten, die von den Teilnehmern als ausgef\u00fchrt akzeptiert werden. Sie sind damit unver\u00e4nderlicher Bestandteil des Ledgers \u00fcber dessen Kopie die Teilnehmer verf\u00fcgen. Die verbleibende Frage ist nun, auf welche Weise die Teilnehmer eines Blockchain-Systems einen Konsens \u00fcber 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<\/a> wurden verschiedene Varianten von Blockchain-Ans\u00e4tzen vorgestellt. Unterschieden wurde in die Dimensionen \u00f6ffentlich\/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\u00e4t 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\u00e4ndig zunimmt. In diesem Beitrag soll ein \u00dcberblick \u00fcber die derzeit relevanten Konsens-Mechanismen gegeben werden. Hervorgehoben werden sollen dabei die Mechanismen von Bitcoin und von Ripple.<\/p>\n

Proof of Work<\/strong><\/h2>\n

Mit Bitcoin, das die Blockchain-Technologie popul\u00e4r gemacht hat, wurde der sog. „Proof of Work“-Algorithmus (PoW) entwickelt. Da es sich bei Bitcoin um eine \u00f6ffentliche und permissionless Blockchain mit sich gegenseitig nicht bekannten Teilnehmern handelt, bestehen hohe Anforderungen an die Sicherheit und Funktionsf\u00e4higkeit des Algorithmus. Prinzipiell kann jeder Teilnehmer im Bitcoin-Netzwerk an der Blockerzeugung mitwirken. Das PoW-Konzept ist dabei so konstruiert, dass ungef\u00e4hr alle 10 Minuten irgendein Teilnehmer des Systems die in dieser Zeit bei ihm angelangten Transaktionen zu einem nicht mehr ver\u00e4nderbaren Block zusammenfasst (vgl. Abbildung 1) [2]. Dieser wird dann an alle verteilt und ist schlie\u00dflich Teil der kollektiven Blockchain. Der Empf\u00e4nger einer Transaktion muss also so lange warten, bis er einen Block bekommt, der die Transaktion enth\u00e4lt. Dann ist sie beglaubigt.<\/p>\n

\"Blockerstellung<\/a>

Abbildung 1: Blockerstellung bei Bitcoin (Mining)<\/p><\/div>\n

Um die Teilnehmer des Bitcoin-Systems zum Erzeugen der Bl\u00f6cke zu bewegen, wird f\u00fcr jeden Block, der Bestandteil der Blockchain wird, eine Belohnung in Form einer festgelegten Anzahl an Bitcoins gew\u00e4hrt. 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\u00e4tzlich erh\u00e4lt der Miner die in den Transaktionen enthaltenen Transaktionsgeb\u00fchren. Aufgrund der Belohnung besteht ein Anreiz, an der Blockerzeugung mitzuwirken. Damit gesichert ist, dass nur ungef\u00e4hr alle 10 Minuten ein Block erzeugt wird, muss die Software des Miners neben der \u00dcberpr\u00fcfung der Transaktionen noch eine Rechenaufgabe l\u00f6sen. Diese passt sich im Schwierigkeitsgrad automatisch an die am Mining beteiligte Rechenleistung an. Je mehr Teilnehmer also an dem Mining teilnehmen bzw. je st\u00e4rker 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\u00fcr die Aktualisierung der Blockchain bei den Teilnehmern mit einem neuen Block kann es vorkommen, dass zwei oder mehrere Miner gleichzeitig Bl\u00f6cke 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\u00e4r in Verzweigungen zerfallen. Um dies zu korrigieren, sieht der PoW-Algorithmus vor, dass das Mining immer am l\u00e4ngsten Zweig der Blockchain fortgesetzt wird [1]. Damit stabilisiert sich die Blockchain von selbst. Um sicherzustellen, dass nur der Miner die Belohnung erh\u00e4lt, dessen Block sich durchgesetzt hat, wird die Auszahlung vom System entsprechend verz\u00f6gert. Aufgrund seiner Konstruktion hat sich der PoW-Ansatz von Bitcoin bis heute trotz zahlreicher Angriffe als funktionsf\u00e4higes Konzept erwiesen. Die Mehrzahl der Transaktionen in der Blockchain haben noch Bitcoins zum Gegenstand, jedoch ist das Transaktionsbuch offen konstruiert, d.h. prinzipiell k\u00f6nnen auch andere Assets (bzw. deren digitale Repr\u00e4sentanten) \u00fcber die Bitcoin-Blockchain transferiert bzw. verwaltet werden. Dies nutzen bereits viele Blockchain-basierte Dienste. Zudem k\u00f6nnen Regeln in der Blockchain von Bitcoin angelegt werden, womit sich (unter Beschr\u00e4nkungen) auch Smart Contracts realisieren lassen. Allerdings weist das Bitcoin-Konzept auch einige Problembereiche auf, die es f\u00fcr eine umfassendere Nutzung sowie f\u00fcr bestimmte Anwendungsbereiche nur bedingt brauchbar machen. Einige dieser Problembereiche sind dabei zumindest von der technischen Seite durch Anpassungen leicht zu beheben. Dazu geh\u00f6rt beispielsweise die limitierte Blockgr\u00f6\u00dfe, die bei der derzeitigen Konfiguration nur ca. 600.000 Transaktionen pro Tag erm\u00f6glicht. Andere Problembereiche sind dagegen systemimmanent und somit nur schwer bis gar nicht zu l\u00f6sen. 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\u00fcnden abgelehnt werden und ggfs. einen l\u00e4ngeren Zeitraum ben\u00f6tigen, um von einem anderen Miner in die Blockchain aufgenommen zu werden [4]. Desweiteren sch\u00fctzt der PoW-Algorithmus nur so lange vor Manipulationen, wie sich die Mining-Leistung \u00fcber viele Teilnehmer verteilt. Verf\u00fcgt ein Miner \u00fcber einen l\u00e4ngeren Zeitraum \u00fcber mindestens 51% der Mining-Leistung, so kann er die Blockchain (auch r\u00fcckwirkend) 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\u00f6ht und gleichzeitig konzentriert, so dass eine entsprechende Gef\u00e4hrdung gegeben ist. Auch aus \u00f6kologischer Sicht ist das Bitcoin-Netzwerk bedenklich. Anfang Januar 2016 wurden pro Sekunde im Bitcoin-System \u00fcber 900 Billiarden Berechnungen zur Bew\u00e4ltigung der Rechenaufgabe vorgenommen [5]. F\u00fcr die Erzeugung eines Blocks werden ca. 6000 Sekunden (10 Minuten) ben\u00f6tigt. Nach Sch\u00e4tzungen 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\u00fcnstigen Preise f\u00fcr Elektrizit\u00e4t werden die gro\u00dfen 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\u00e4ltigung der oben genannten Problembereiche werden dabei in der Regel Variationen gegen\u00fcber dem Ansatz von Bitcoin vorgenommen. Ein Beispiel daf\u00fcr ist die Einf\u00fchr
\nung einer sog. Mining-Diversity, die die Anzahl der Bl\u00f6cke, die ein Teilnehmer innerhalb eines gegebenen Zeitintervalls erzeugen kann, beschr\u00e4nkt [4].<\/p>\n

Proof of Stake<\/strong><\/h2>\n

Zudem wurden alternative „Proof of“-Mechanismen entwickelt, insbesondere um die Blockerzeugung unabh\u00e4ngig von der Rechenleistung zu machen und zu k\u00fcrzeren Blockerzeugungszyklen zu gelangen. Einen \u00dcberblick geben [7] und [8]. Eine viel diskutierte Alternative ist der „Proof of Stake“-Ansatz (PoS). Hier h\u00e4ngt die Wahrscheinlichkeit f\u00fcr die Erzeugung eines Blocks durch einen Teilnehmer von dessen wertm\u00e4\u00dfigem Anteil am Netzwerk ab, d.h. dem Anteil seines Verm\u00f6gens in der jeweiligen virtuellen W\u00e4hrung am Gesamtverm\u00f6gen. 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\u00e4ufig wechselnde Teilmengen bestimmt werden, denen dann die Blockerzeugung gestattet ist. Andere Ans\u00e4tze kombinieren PoS und PoW zu hybriden Konzepten, so dass beispielsweise das System prim\u00e4r \u00fcber einen PoS-Ansatz funktioniert, Zusammenfassungen dieser prim\u00e4ren Blockchain jedoch in regelm\u00e4\u00dfigen Abst\u00e4nden in der Bitcoin-Blockchain zwecks zus\u00e4tzlicher Absicherung der Transaktionen gegen\u00fcber Manipulationen gespeichert werden, auch Blockchain Anchoring genannt.<\/p>\n

Der Ripple Protocol Consensus Algorithmus<\/strong><\/h2>\n

Die bislang dargestellten Konsensmechanismen basieren darauf, dass ein Teilnehmer einen neuen Block erzeugt und dieser dann im Netz verteilt wird. Bis zur vollst\u00e4ndigen Synchronisation des Netzes entsteht damit ein Zeitbedarf, der die Zeitdauer der Blockerzeugung plus die der vollst\u00e4ndigen Verteilung umfasst. Einen v\u00f6llig anderen Weg gehen die Konsensmechanismen, die Anbieter wie Ripple und Hyperledger verwenden. Es handelt sich hierbei um iterative Ans\u00e4tze, bei denen sich die Knoten gemeinsam und zeitgleich auf den n\u00e4chsten Block einigen. Die Funktionsweise soll stellvertretend f\u00fcr den Ripple Protocol Consensus Algorithm (RPCA) dargestellt werden [9]. Wie in allen Blockchain-basierten Netzen nehmen auch bei Ripple Knoten Transaktionen entgegen, \u00fcberpr\u00fcfen 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\u00f6tigt und die Transaktionen von unterschiedlichen Knoten eingebracht werden, haben die einzelnen Knoten in der Regel unterschiedliche B\u00fcndel an Kandidaten, auch als Candidate Set bezeichnet (siehe \u2460 in Abbildung 2). Das Ziel des Konsensalgorithmus besteht nun darin, sich auf die gemeinsame Teilmenge der Kandidaten zu einigen, die dann dem Ledger hinzugef\u00fcgt wird. Dies geschieht asynchron und iterativ \u00fcber mehrere Runden. Die Knoten m\u00fcssen sich dabei nicht vertrauen, es wird lediglich angenommen, dass es keine umfangreichen konspirativen Kollaborationen gibt.<\/p>\n

\"Der<\/a>

Abbildung 2: Der Ripple Protocol Consensus Algorithm
Quelle: http:\/\/youtu.be\/17RtYvWb60o<\/p><\/div>\n

Jeder am Konsensprozess beteiligte Knoten verf\u00fcgt \u00fcber eine Liste von aktiven Knoten, die sog. Unique Node List (UNL) \u2461. Mit diesen Knoten werden sog. Proposals ausgetauscht, die Vorschl\u00e4ge \u00fcber aufzunehmende Transaktionen enthalten. Zu Beginn schickt ein Knoten zun\u00e4chst sein Candidate Set als Proposal an die aktiven Knoten in seiner UNL und erh\u00e4lt im Gegenzug die Proposals der anderen Knoten. Die in den fremden Proposals enthaltenen Transaktionen werden nun mit denen im eigenen Candidate Set verglichen \u2462. 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 \u2463. Der Schwellenwert wird nun auf 60% erh\u00f6ht und die Ausz\u00e4hlung 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\u00e4chsten Runde auf 70% und in der finalen Runde schlie\u00dflich auf 80% erh\u00f6ht. 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 \u2464. Um sicherzugehen, dass jeder Knoten auch tats\u00e4chlich den gleichen Block erzeugt hat, werden schlie\u00dflich noch deren digitalen Fingerabdr\u00fccke untereinander ausgetauscht. Der Zeitbedarf f\u00fcr 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\u00e4chsten Konsensprozess ein.<\/p>\n

Schlussbemerkungen<\/strong><\/h2>\n

Die Darstellungen in diesem Beitrag haben gezeigt, dass bereits einige Konsensmechanismen existieren, die in der Praxis einsatzf\u00e4hig sind. Aufgrund ihrer unterschiedlichen Konstruktionen eignen sie sich dabei auch in unterschiedlicher Weise in Abh\u00e4ngigkeit von ihrem Einsatzbereich. So ist es z.B. fraglich, ob in einem privaten und permissioned Blockchain-System ein aufw\u00e4ndiger PoW-Ansatz n\u00f6tig 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\u00f6nnen hier f\u00fcr die Zukunft noch weitere Entwicklungen erwartet werden, um die unterschiedlichen Bed\u00fcrfnisse der Praxis abzudecken.<\/p>\n

Zur\u00fcck zu Teil 2<\/a><\/p>\n

Zur\u00fcck zu Teil 1<\/a><\/p>\n

Literatur<\/strong><\/h2>\n

[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\u00dfes Problem: Die Krypto-W\u00e4hrung 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. \u00a0<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

Teil 3: Konsens-Mechanismen Einleitung Im ersten Teil dieser Beitragsreihe wurde dargestellt, dass die Blockchain eine kryptografisch verbundene Kette von in Zeitintervallen erstellten Bl\u00f6cken ist, die diejenigen Transaktionen aus dem jeweiligen Intervall enthalten, die von den Teilnehmern als ausgef\u00fchrt akzeptiert werden. Sie sind damit unver\u00e4nderlicher Bestandteil des Ledgers \u00fcber dessen Kopie die Teilnehmer verf\u00fcgen. Die verbleibende […]<\/p>\n","protected":false},"author":481,"featured_media":14867,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1221,38,33],"tags":[473,442,429,100,101],"class_list":["post-5102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bachelor-of-science-bba","category-management-research","category-research-and-advisory","tag-bitcoin","tag-blockchain","tag-fintech","tag-newsletter-de","tag-newsletter-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/posts\/5102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/users\/481"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/comments?post=5102"}],"version-history":[{"count":7,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/posts\/5102\/revisions"}],"predecessor-version":[{"id":34680,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/posts\/5102\/revisions\/34680"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/media\/14867"}],"wp:attachment":[{"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/media?parent=5102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/categories?post=5102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.frankfurt-school.de\/de\/wp-json\/wp\/v2\/tags?post=5102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}