Suchen

Dezentralisierte Übereinstimmung Konsensus-Engines auf dem Prüfstand

| Autor/ Redakteur: Anna Kobylinska und Filipe Martins / Peter Schmitz

In einem Blockchain-Ökosystem „dreht sich“ alles um die Konsensus-Engine: Metriken wie der Transaktionsdurchsatz und horizontale Skalierbarkeit wie auch die Fähigkeit zur Umsetzung berechtigungs­pflichtiger Zugriffe, byzan­tinischer Fehlertoleranz und anderer Features stehen im direkten Zusammenhang mit diesem Verfahren.

Firmen zum Thema

Sollen autarke Teilnehmer gemeinsam handeln, müssen sie erst einmal einen Konsens erreichen. Soweit so gut, aber wie?
Sollen autarke Teilnehmer gemeinsam handeln, müssen sie erst einmal einen Konsens erreichen. Soweit so gut, aber wie?
(© metamorworks - stock.adobe.com)

Das Konsensverfahren beeinflusst die erzielbare Transaktionsrate, das Potenzial für Skalierbarkeit des Netzwerks, den Grad der Offenheit und Dezentralisierung, die byzantinische Fehlertoleranz und zahlreiche andere Merkmale der Blockchain-Plattform.

Konsensmechanismen gibt es dementsprechend in Hülle und Fülle. Die Vielfalt sorgt auch für viel Verwirrung. Einige der größten Missverständnisse rund um die Blockchain zentrieren sich um die vertrauenslose Natur der Blockkette, glauben u.a. die Analysten von Ernst & Young. Gängige Missverständnisse beginnen schon bei den Begrifflichkeiten.

Ohne Sybil-Abwehr keine Konsensfindung

Das Konsensverfahren bestimmt, wie die autarken Teilnehmer eines Blockchain-Netzwerks das dezentralisierte Transaktionsprotokoll gemeinsam verwalten. Das übergeordnete Ziel besteht darin, die autoritative Chain zu identifizieren und ihre Integrität zu wahren. Berechtigte Netzwerkknoten müssen hierzu immer wieder über den Zustand der Blockchain anhand der verfügbaren Replikas abstimmen. Die einzelnen Teilnehmer können hierzu für ihre Wartungsaufgaben finanzielle Anreize bekommen.

Die kleinen Feinheiten: Prof. Emin Gün Sirer von der Cornell-Universität, einer der führenden Blockchain-Experten, fordert seit Jahren einen Konsensus rund um die Begrifflichkeiten.
Die kleinen Feinheiten: Prof. Emin Gün Sirer von der Cornell-Universität, einer der führenden Blockchain-Experten, fordert seit Jahren einen Konsensus rund um die Begrifflichkeiten.
(Bild: Emin Gün Sirer)

Proof of Work und Proof of Stake, die wohl zwei bekanntesten Blockchain-spezifischen Vorgehensweisen, seien gar keine Konsensverfahren, beobachtet Prof. Emin Gün Sirer. Bei Proof-of-Work (PoW) und Proof-of-Stake (PoS) handelte sich nicht um Konsensverfahren, sondern um Sybil-Kontrollmechanismen, gibt Prof. Sirer zu bedenken. Er weiß, wovon er spricht. Als einer der Krypto-Pioniere und Inhaber des Lehrstuhls für Informatik an der Cornell-Universität gilt er als ein international anerkannter Blockchain-Experte.

Bei einer Sybil-Attacke ist von einem Versuch die Rede, mit Hilfe von einer Reihe gefälschter Identitäten das Verhalten eines Peer-Netzwerks heimlich zu manipulieren (zum Beispiel via unlautere Stimmrechte oder Echokammer-Nachrichten). Sollte ein Blockchain-Netzwerk infolge einer Sybil-Attacke Konsensus erreichen, wäre die Unveränderlichkeit Transaktionsprotokolls nicht mehr gewährleistet, mit potenziell gravierenden Folgen für das Eigentum „blockchainerisierter“ Vermögenswerte. Aus diesem Grunde ist Sybil-Abwehr von überragender Bedeutung und ein unverzichtbares Element der Konsensus-Engine.

Ein Sybil-Kontrollmechanismus wie PoS würde nicht ausreichen, um den Konsensus zu erreichen, bestätigt Prof. Sirer. Das Verfahren müsse erst mit einem Protokoll wie Practical Byzantine Fault Tolerance (PBFT) oder Ben-Or oder Tendermint/Cosmos oder Avalanche kombiniert werden, um die Entscheidungsfindung zu ermöglichen. In BTC/BCH käme PoW beispielsweise im Zusammenspiel mit der heaviest/longest-Chain-Auswahlregel zum Tragen; erst in dieser oder in einer vergleichbaren Konstellation sei die Konsensfindung möglich. Auch PoW allein führe nicht zum Konsensus, sondern lediglich zur Beschränkung der Transaktionsrate (eine geeignete Maßnahme, um etwa Spam abzuwehren).

Die „Konsensus-Engine“ einer Blockchain-Plattform, die „de-zentrale Drehscheibe“ der Entscheidungsfindung, muss also zwei Elemente miteinander verbinden: ein Protokoll und einen Sybil-Kontrollmechanismus. In der Umgangssprache der Blockchain-Gemeinde außerhalb der Akademia werden diese beiden Begriffe der Vereinfachung zuliebe austauschbar verwendet.

Zwischen Proof of Work und Proof of Stake

Sybil-Arttacken gegen das Netzwerk stellen die größte Bedrohung für die Integrität der Blockchain dar und so gebührt ihnen besondere Aufmerksamkeit im Rahmen der Konsensfindung.

Geforkt: Konsensfindung bei Proof-of-Work läuft darauf hinaus, dass sich alle Teilnehmer letztendlich auf den längsten Chain einigen, in dem die meiste Rechenzeit steckt (im Beispiel in lila gekennzeichnet).
Geforkt: Konsensfindung bei Proof-of-Work läuft darauf hinaus, dass sich alle Teilnehmer letztendlich auf den längsten Chain einigen, in dem die meiste Rechenzeit steckt (im Beispiel in lila gekennzeichnet).
(Bild: mastanbtc.github.io)

Proof of Work (kurz PoW) ist die älteste Methode zum Schutz der Blockchain gegen Sybil-Attacken. Sie ist u.a. bei Bitcoin, Litecoin und Ethereum 1.0 im Einsatz, wo sie auf Grund der hohen Kosten und der lahmen Transaktionsverarbeitung zu viel Unmut beiträgt. Um neue Transaktionen registrieren zu können, müssen sich die betreffenden Teilnehmer, die sogenannten „Miner“, durch zuvor geleistete Rechenarbeit qualifizieren (wenn sie es für einen Block nicht rechtzeitig schaffen, haben sie umsonst geschürft). Diese Methode der Konsensfindung erreicht eine sehr niedrige Transaktionsgeschwindigkeit und erfordert einen enormen Energieaufwand. Das weltweite Bitcoin-Mining verschlingt jährlich so viel Energie wie 63 Prozent der Wirtschaft der Tschechischen Republik — nicht gerade „grün“. Kritiker bemängeln außerdem die zunehmende Zentralisierung der Macht über das Netzwerk in der Hand von nur wenigen Mining-Pools und die damit verbundenen Sicherheitsrisiken. So ist es kein Wunder, dass Ethereum, die führende öffentliche Blockchain zur Umsetzung von smarten Verträgen mit Enterprise-Ansprüchen, sich von dem PoW-Verfahren distanzieren möchte und dabei ist, eine Umstellung auf ein anderes Verfahren zu vollziehen (siehe dazu auch den Bericht „Der Ethereum Hard-Fork Istanbul“).

Proof of Stake (kurz: PoS) setzt auf die sogenannten Validator-Knoten, also eine Untermenge aller Teilnehmer, die sich durch das Einlegen einer Kaution zum Nachweis ihres begründeten Interesses an der Integrität des Netzwerks für das Beglaubigen von Transaktionen qualifiziert haben. Diese Methode der Konsensfindung ist energieschonender und schneller als PoW, bremst jedoch die Zahlungsbereitschaft aus, weil sie hohe Kapitaleinlagen einfriert.

PoS ist leider auch nicht immun gegen Manipulationen. Das Casper-Konsensprotokoll, die PoS-Variante, die für Ethereum 2.x ansteht, implementiert zusätzliche Absicherungen gegen gängige Attacken (siehe dazu den Abschnitt weiter unten). Es gibt aber auch unzählige andere Varianten für diverse besonderen Ansprüche.

Delegated Proof of Stake oder DPoS ist eine Variante von PoS, die sich im Einsatz z.B. bei Steem und Lisk bewähren konnte. Die Teilnehmer wählen in einer kontinuierlichen Abstimmung die sogenannten Witnesses, also Netzwerkknoten, die dazu berechtigt sind, Transaktionen zu bezeugen. Die Stimmrechte der Witnesses ergeben sich aus dem Wert der von ihnen eingelegten Token. Einige Witnesses bekommen für ihren Dienst eine Vergütung.

Proof of Activity (PoA) ist ein Hybrid aus PoW und PoS. PoW wechselt zwischen den beiden Verfahren im Verlauf der Transaktionsverarbeitung hin und her, um das Beste aus beiden Welten in einer einzigen Konsensengine zu vereinbaren. Kritiker wenden ein, dass es das Schlechteste aus beiden Varianten unter einen Hut bringt. Das Verfahren ist u.a. beim Blockchain-Netzwerk der Kryptowährung Decred im Einsatz.

Alternative Verfahren zu Sybil-resistenter Konsensfindung

Federated Byzantine Agreement (kurz: FBA) ist eine andere Sybil-Abwehrmaßnahme, die u.a. in der Konsensus-Engine von Stellar zum Einsatz kommt. Die Mitgliedschaft im Netzwerk ist offen, die Steuerung ist dezentral, jedoch anstelle eines Quorums setzt das Verfahren auf Quorum-Slices, also sich gegenseitig überlappende Untermengen der berechtigten Knoten. Die einzelnen Knoten suchen sich selbst aus, welchen Quorum-Slices sie vertrauen möchten. Die einzelnen Quorum-Slices sollten sich vorzugsweise überlappen, um widersprüchliche Transaktionen (die gefürchtete Blockchain-Divergenz) unterdrücken zu können. So kommt der Konsensus dezentralisiert zu Stande. Im Übrigen ist es nicht erforderlich, dass jeder der Knoten vorab bekannt ist und auf seine Vertrauenswürdigkeit hin überprüft wurde; die ausgefuchste Sybil-Abwehr macht es möglich.

Practical Byzantine Fault Tolerance (kurz: pBFT) kommt z.B. bei Hyperledger Fabric, Sawtooth und Zilliqa zum Tragen. Das pBFT-Verfahren verleiht der Blockchain byzantinische Fehlertoleranz (also macht sie immun gegen die Aktivitäten heimtückisch böswilliger Netzwerkteilnehmer) unter der Annahme, dass unabhängige Knotenausfälle und manipulierte Nachrichten ganz bestimmten unabhängigen Knoten entstammen, die niemals mehr als (n-1)/3 aller Knoten ausmachen.

Im Wesentlichen besteht das Netzwerk aus einem Primärknoten (dem Leader) und aus Sicherungsknoten (der Leader wechselt im Round-Robin-Verfahren). Alle Knoten innerhalb des Systems kommunizieren intensiv miteinander, wobei sie sowohl den Ursprung als auch die Integrität der Nachrichtenübertragung gegenüber dem jeweiligen Empfänger nachweisen müssen. Die ehrlichen Knoten erreichen dann einen Konsensus. Der Algorithmus wurde für asynchrone Systeme entwickelt; bei einer geringen Anzahl von Knoten zeichnet es sich durch eine hohe Leistung mit einer beeindruckenden Overhead-Laufzeit und einer nur geringen Latenzsteigerung. Es ist energieeffizienter als ein reines PoW-System, jedoch anfällig für Sybil-Attacken (ein Knoten kann viele andere Knoten manipulieren), insbesondere bei einer kleinen Netzwerkgröße. Bei größeren Netzen steigt wiederum der Overhead. pBFT eignet sich daher am besten für berechtigungspflichtige Blockchains; in öffentlichen Blockchains kommt es in einer hybriden Implementierung zum Einsatz.

Das Raft-Verfahren kommt zum Beispiel bei Hyperledger Sawtooth zum Einsatz. Die Teilnehmer des Blockchain-Netzwerks splitten sich anfangs in Followers und (ebenfalls mehrere) Kandidaten für den sogenannten Leader auf. Das Netzwerk benötigt einen Leader, um die Erstellung von Blöcken zu synchronisieren und ein Protokoll aufzuzeichnen. Followers ohne einen Leader bieten sich umgehend als Candidates an und halten eine Abstimmung ab, aus der ein Leader hervorgeht (die Knoten stimmen für den jeweiligen Zustand der Blockchain ab; so entsteht Konsensus). Dieser Knoten sendet dann ein Heartbeat-Signal an die übrigen Teilnehmer, solange er seine Aufgaben der Blockchain-Pflege wahrnehmen kann; diese replizieren den aktuellen Zustand der Blockchain untereinander.

Transaktionsfinalität mit byzantinischer Fehlertoleranz: Schematische Darstellung der Interaktionen des Primärknoten (N1) mit den Sekundärknoten (N2-N4) in Hyperledger Sawtooth beim Einsatz von PBFT.
Transaktionsfinalität mit byzantinischer Fehlertoleranz: Schematische Darstellung der Interaktionen des Primärknoten (N1) mit den Sekundärknoten (N2-N4) in Hyperledger Sawtooth beim Einsatz von PBFT.
(Bild: Hyperledger)

Ein Konsensverfahren, welches einem diametral anderen Ansatz folgt, ist Intels Proof of Elapsed Time (PoET), im Einsatz unter anderem bei Sawtooth. PoET ist darauf ausgelegt, die Nutzungseffizienz der Ressourcen zu maximieren und den Energieverbrauch zu minimieren (also das Gegenteil von PoW). PoET macht sich hierzu ein Lotteriesystem zu Nutze. Jeder Knoten wählt eine zufällige Wartezeit und schaltet für diese Dauer in einen inaktiven Zustand um; welcher Knoten auch immer gerade zufällig seine Wartezeit beendet, wird zum Leader der anstehenden Validierung des nächsten Datenblocks. Diese Vorgehensweise setzt natürlich ein Blockchain-Netzwerk voraus, in dem nur ehrliche, identifizierbare, nicht manipulierbare Knoten mitspielen. Das Verfahren entstand bei Intel und setzt auf eine vertrauenswürdige Ausführungsumgebung auf der Basis von Intel Software Guard Extensions (SGX), einem proprietären CPU-Befehlssatz, auf. Der Vorteil dieses „hardwarebeschleunigten“ Konsensverfahrens ist seine enorme Skalierbarkeit.

Angriffsvektoren gegen PoS

Die bevorstehende Umstellung von Ethereum von Proof of Work auf Proof of Stake (Casper) ist seit Monaten in Arbeit und in aller Munde. Doch auch hier sind Probleme nicht ausgeschlossen. Gängige Attacken, die es bei PoS abzuwehren gilt, reichen vom „nothing-at-stake“-Betrug („nichts-zu-verlieren-Attacke“) über Long-Range-Attacks bis hin zur Kartellbildung. Es bleibt spannend.

Zuckerbrot und Peitsche: Mit Consensus-by-Bet befolgt Casper eine grundlegend neue Philosophie der Konsensfindung. Erfolgreiche Validators bekommen ihren Einsatz vergütet. Wer sich irrt, zahlt drauf.
Zuckerbrot und Peitsche: Mit Consensus-by-Bet befolgt Casper eine grundlegend neue Philosophie der Konsensfindung. Erfolgreiche Validators bekommen ihren Einsatz vergütet. Wer sich irrt, zahlt drauf.
(Bild: Ethereum.org)

Validator-Knoten in einer naiven PoS-Implementierung können die Sicherheit der Blockchain aushebeln, indem sie gleichzeitig für mehrere widersprüchliche Blöcke abstimmen, um ihren Erlös zu maximieren, ohne dafür bestraft zu werden. Diese sogenannte „nothing-at-stake“-Attacke („nichts-zu-verlieren-Attacke“) kommt dann zu Stande, wenn den Validators Anreize fehlen, um sich auf eine einzelne Kette festzulegen. Bei PoW stellt sich das Problem nicht, weil die verfügbare Hashing-Leistung eine beschränkende Größe darstellt.

Als eine Gegenmaßnahme nutzt Casper Vitalik Buterins „Slasher“, eine Funktion zum Bestrafen unehrlicher Validators. Eine Long-Range-Attacke (Revisionsangriff) kommt dann zu Stande, wenn ein Angreifer weit in der Blockchain zurück geht und beginnt, betrügerische Blöcke vor sich hin zu erzeugen.

Die Verwundbarkeit der Blockchain gegen diese Attacke entsteht im Zusammenhang mit dem Problem der schwachen Subjektivität (Weak Subjectivity). Einem neuen Knoten, der erst noch eine Replika der Blockchain aus dem Netzwerk beziehen muss, stehen keinerlei objektiven Kriterien zur Verfügung, um die aktuelle Mainchain korrekt zu erkennen. (Bei PoW mag die Länge der Kette einen Aufschluss über die investierte Rechenzeit geben, aber bei PoS ist dieses Kriterium bedeutungslos).

Bei PoS kann ein Angreifer solche naiven Neuzugänge leicht hinters Licht führen, sodass sich diese im guten Glauben der falschen Chain anschließen und neue Datenblöcke für validieren. Dem Betrüger stehen aber auch noch zahlreiche andere Methoden zur Verfügung, um die benötigten Validators für den Raubüberfall zu gewinnen. Da im Falle von PoS der Rechenaufwand minimal ausfällt (sog. Costless Simulation) und die betrügerische Chain ja ohnehin mit fiktiven smarten Verträgen hantieren kann, bekommt sie gegenüber der Mainchain schnell einen Vorsprung.

Mit dieser Methode kann der Angreifer, auch wenn er nicht jeden Block selbst validieren darf, eine alternative Kette aufbauen und letztendlich zur Mainchain küren. So wird die Unveränderlichkeit der Blockchain zur reinen Illusion. Noch schlimmer: Kein einziger Workaround bietet bisher zuverlässigen Schutz gegen diese Art von Attacken beim Einsatz von PoS. Eine erfolgreiche Abwehr gelingt erst durch den Einsatz ausgefeilter Kombinationstechniken (u.a. Moving Checkpoints, Context-Aware Transactions, Key-Evolving Cryptography und die sog. Plenitude-Regel).

Fazit

In einem Blockchain-Ökosystem „dreht sich“ alles um die Konsensus-Engine: Metriken wie der Transaktionsdurchsatz und horizontale Skalierbarkeit wie auch die Fähigkeit zur Umsetzung berechtigungs­pflichtiger Zugriffe, byzantinischer Fehlertoleranz und anderer Features stehen im direkten Zusammenhang mit diesem Verfahren. Den springenden Punkt stellen aber im Endeffekt die gebotenen Schutzmechanismen gegen Sybil-Attacken dar. Mit der Wirksamkeit dieser Verfahren steht und fällt die Integrität der Blockkette und damit das Vertrauen.

Über die Autoren: Anna Kobylinska und Filipe Pereira Martins arbeiten für McKinley Denali Inc. (USA).

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 46281474)