Beiträge

Blockchain verbraucht zu viel Strom – Performance, Consensus und das CAP-Theorem

15.3.2019 / Falk Borgmann, Strategy Consultant, Deepshore GmbH

"Blockchain ist aus moralischen und nachhaltigen Gesichtspunkten nicht zu akzeptieren, da die Technologie zu viel Strom verbraucht!" Diesen Satz habe ich in abgewandelter Form schon mehrfach vernommen. Dabei wird deutlich, dass immer noch die Bitcoin-Implementierung mit der Blockchain als Konzept bzw. Technologie verwechselt wird. Der „Proof of Work“-Mechanismus von Bitcoin (im folgenden PoW), welcher tatsächlich unverhältnismäßig viel Energie für Mining-Aktivitäten verbraucht, wurde von den Entwicklern dieser Welt schon lange als Problem identifiziert. Aus diesem Grund gibt es mittlerweile zahlreiche alternative Ansätze. Egal ob Proof of Stake, Proof of Elapsed Time, Proof of Authority oder auch die Mining Diversity, es handelt sich um Konzepte, die bekannte Schwachstellen oder Lücken des Bitcoin-PoW beseitigen wollen. So sollen unter anderem der Aufwand und die Laufzeit von Rechenoperationen verringert werden, um die Energiekosten bzw. Latenzen zu senken.

Bei dieser Diskussion, um die Nachteile des PoW darf nicht vergessen werden: Der Proof of Work ist in der vorhandenen Form erstmals in der Bitcoin-Blockchain produktiv zum Einsatz gekommen. Es handelt sich bei Bitcoin um die erste richtige Blockchain, mit weltweit durchschlagendem Erfolg. Und im Verhältnis zu anderen IT-Systemen, die praktisch neu erfunden wurden, funktioniert der PoW im Kontext seiner Implementierung sehr verlässlich, wenn auch mit einigen Nachteilen. Selbst Ethereum wagt sich seit langer Zeit mit seinen alternativen (z. B. Proof of Stake) Ansätzen nicht aus dem Schatten des PoW.

Im Vergleich zur klassischen verteilten Datenbank muss sich eine Blockchain-Implementierung eben auch noch um das so genannte Mining kümmern: Ein verteiltes Blockchain-Cluster muss nicht nur eine Übereinkunft darüber treffen, welcher Wert oder welche Transaktion zu welchem Zeitpunkt richtig oder falsch ist, sondern zusätzlich auch noch, welcher Teilnehmer den nächsten Block minen darf. Ein klassischer Consensus Algorithmus regelt also:

  • was richtig ist,
  • wann es richtig ist und
  • wie dieses Ergebnis erreicht wird.

Bei Bitcoin kann die Bestimmung des Wie, nämlich das Lösen einer Rechenaufgabe (PoW), um den nächsten Block samt neuer Transaktionen (Was) zu minen, also durchaus als Teil der Consensus-Funktionalität bezeichnet werden. Hier gibt es aktuell unterschiedliche Sichtweisen und Debatten unter den Fachleuten, ob der PoW nun ein Element des Consensus ist oder nicht.

Bei all den Diskussionen um technische Implementierungen sowie deren Vor und Nachteile in puncto Geschwindigkeit, Redundanz, Verlässlichkeit, ökologischer Fußabdruck etc. sollte ein wichtiger Grundsatz von verteilten Systemen nicht vergessen werden – das CAP-Theorem. Es besagt, dass in einem verteilten System drei Dinge nicht gleichzeitig sichergestellt werden können: Konsistenz (C = Consistency), Verfügbarkeit (A = Availability) und Ausfalltoleranz (P = Partition Tolerance). So wie jedes verteilte System, muss sich auch eine Blockchain-Implementierung an diesen Grundsatz halten. Bei einem großen öffentlichen Blockchaincluster wie Bitcoin kann der Ausfall eines einzelnen Knotens leicht verkraftet werden und dennoch ist das System in der Lage, Transaktionen weiter durchzuführen. Die Verfügbarkeit des Gesamtsystems ist durch die Vielzahl von Instanzen gleichermaßen sichergestellt. Erkauft werden sich diese beiden Vorteile u. a. durch den etwas zähen PoW und dessen asynchrone Validierung, die in letzter Konsequenz dazu führt, dass eine Transaktion relativ lange benötigt, um innerhalb des Clusters auch wirklich bei jeder Instanz gesichert vorhanden zu sein. Hier wird klar, dass der Consensus und somit das gesamte Systemdesign direkt mit der Performance zusammenhängen. Würde man in einem verteilten System die Konsistenz als oberste Direktive vorsehen, müsste eine technische Lösung zwangsläufig auf seine uneingeschränkte Verfügbarkeit oder aber auf seine Ausfalltoleranz verzichten.

Warum? Zum Beispiel müsste in einem verteilten Cluster, um zu jeder Zeit eine konsistente (also identische) Antwort zu erhalten, gewährleistet sein, dass jede Instanz, die von außen nach einer Information gefragt werden kann, zuverlässig über die aktuellste Information verfügt. Das könnte so gelöst werden, dass vor der Antwort an den fragenden Client durch eine vorherige Rückfrage bei allen anderen Cluster-Instanzen sichergestellt wird, was die aktuellste/richtige Information ist. Der Koordinator, der diese Anfrage innerhalb des Clusters verteilt (also derjenige, der die Anfrage von außen erhielt), würde diese Aufgabe als fest definierte einzelne Instanz übernehmen. Sollte er selbst oder einer seiner Peers in der Anfrage-Zeit ausfallen, könnte ein System auch nicht mehr hundertprozentig sicherstellen, dass allein der ausgefallende Knoten die aktuellste Information hatte, die jedoch noch nicht repliziert wurde. Ein konkretes Beispiel wäre der RAFT-Algorithmus, der zugunsten von Konsistenz und Ausfalltoleranz einzelner Knoten auf die uneingeschränkte Systemverfügbarkeit verzichtet. (Die Funktionsweise des RAFT-Algorithmus werde ich in einem folgenden Artikel detaillierter beschreiben.)

Fazit

Die Performance und der Energieverbrauch eines Blockchain-Systems hängt u. a. mit dem verwendeten Consensus, aber auch mit der Systemarchitektur zusammen. Ferner eignet sich das CAP-Theorem, um im Vorfeld eines Projektes die fachlichen Ziele mit den technischen Möglichkeiten einer verteilten Architektur (auch mit deren Nachteilen) abzugleichen. Ich empfehle deshalb allen, die sich mit verteilten Systemen (u. a. Blockchain) beschäftigen, sich auch mit dem CAP-Theorem auseinanderzusetzen.

Aus unserem Special
»BLOCKCHAIN: COMPLIANCE FÜR DIE BUSINESS CLOUD«
Beitrag 10/19
Teilen: