Das Konsensproblem erfordert die Abstimmung zwischen mehreren Prozessen bzw. Agenten für einen einzelnen Datenwert. Einige der Prozesse oder Agenten können fehlschlagen oder auf andere Weise unzuverlässig sein. Die Prozesse müssen irgendwie ihre Kandidatenwerte hervorbringen, miteinander kommunizieren und sich auf einen einzigen Konsenswert einigen. Das Konsensproblem ist ein grundsätzliches Problem bei der Steuerung von Multi-Agenten-Systemen wie bei der Blockchain.

Keine Panik. Hinter jeder großen Kryptowährung steckt ein großer Konsens-Algorithmus. Kein Konsensverfahren ist perfekt, aber jeder hat seine Stärken. In der Welt der Kryptographie gibt es Konsensverfahren, um Doppelausgaben zu vermeiden. Hier ein kurzer Überblick über einige der populärsten Konsensverfahren, von Blockchains bis zu DAGs und alles dazwischen.

Proof-of-Work (PoW)

Überblick:
Implementierung: Bitcoin, Ethereum, Litecoin, Dogecoin
Vorteile: Formal und praktisch bewiesene Resilienz
Nachteile: Nicht performant, hoher Energiebedarf
Eignung: für Public, permissionless Blockchains

Der PoW war der erste Blockchain spezifische Konsensus Algorithmus. Das Dezentralisierungs-Hauptbuchsystem sammelt alle Informationen zu den Blöcken. Allerdings muss man besonders auf alle Transaktionsblöcke achten. Diese Verantwortung fällt auf alle individuellen Knoten, die Miner genannt werden und der Prozess, den sie verwenden, um sie zu führen, heißt Mining. Das zentrale Prinzip dieser Technologie ist es, komplexe mathematische Probleme zu lösen und Lösungen leicht zu verteilen. Konkret wird ein Output erzeugt, welcher schwierig (teuer, zeitaufwendig) zu erstellen, aber für andere leicht zu überprüfen ist und bestimmte Anforderungen erfüllt. Die Erstellung eines Arbeitsnachweises kann ein zufälliger Prozess mit geringer Wahrscheinlichkeit sein, so dass im Durchschnitt viele Versuche erforderlich sind, bevor ein gültiger Proof erstellt wird.
Bitcoin verwendet das Hashcash Proof-of-Work System. Aufgrund der sehr geringen Wahrscheinlichkeit einer erfolgreichen Generierung ist es unvorhersehbar, welcher Arbeitsplatzrechner im Netzwerk den nächsten Block erzeugen kann.
Jeder Block enthält den Hash des vorhergehenden Blocks, so dass jeder Block eine Kette von Blöcken hat, die zusammen eine große Menge an „Arbeit“ enthalten. Das Ändern eines Blocks (was nur möglich ist, wenn ein neuer Block mit dem gleichen Vorgänger erstellt wird) erfordert die Neugenerierung aller Nachfolger und das erneute Ausführen der darin enthaltenen „Arbeit“.

Der große Nachteil

Der Nachweis der Arbeit unterliegt jedoch gewissen Einschränkungen. Das Netzwerk scheint stark zu wachsen und benötigt daher viel Rechenleistung. Dieser Prozess erhöht die gesamte Empfindlichkeit des Systems. 

Die Blockchain-Konsensus Sequenz beruht hauptsächlich auf genauen Daten und Informationen. Die Geschwindigkeit des Systems fehlt jedoch enorm. Wenn ein Problem zu kompliziert wird, braucht es viel Zeit, um einen Block zu erzeugen. Die Transaktion wird verzögert und der gesamte Workflow wird angehalten. Wenn das Blockerzeugungs-Problem (Blockinitialisierung) nicht innerhalb einer bestimmten Zeit gelöst werden kann, wird das Erzeugen von Blöcken eher ein Wunder sein. Wenn das Problem jedoch für das System zu einfach wird, ist es anfällig für DDoS-Angriffe. Außerdem muss die Lösung genauer überprüft werden, da nicht alle Knoten auf mögliche Fehler prüfen können.

Funktionsweise im Kontext einer Blockchain

Zuallererst werden die Miner alle Hashingaufgaben lösen und danach werden neue Blöcke erstellt und Transaktionen danach bestätigt. Es ist unmöglich zu sagen, wie komplex die neue Hashaufgabe sein kann. Es hängt stark von der maximalen Anzahl von Benutzern, der minimalen aktuellen Leistung und der Gesamtlast des Netzwerks ab.

Neue Blöcke kommen mit Hash-Funktion und jede von ihnen enthält die Hashwert des vorherigen Blocks. Auf diese Weise fügt das Netzwerk eine zusätzliche Schutzebene hinzu und verhindert jegliche Art von Verstößen. Sobald ein Miner den Hashwert findet, wird ein neuer Block erstellt und die Transaktion bestätigt.

Warum verwenden verschiedene Blockchain-Technologie überhaupt Proof-of-Work?

Das liegt daran, dass der Proof-of-Work Algorithmus einen sehr guten DDoS-Schutz bietet. Dieser Blockchain-Algorithmus bietet den Hackern erhebliche Schwierigkeiten. Das System erfordert viel Rechenleistung und Aufwand.

Dies ist der Grund, warum Hacker sich in die Blockchain-Konsensus-Modelle einklinken können, aber es würde viel Zeit und Komplexität kosten, was die Kosten zu hoch machen würde.

Auf der anderen Seite können sich keine Miner einfach mit viel Geld über das gesamte Netzwerk hinweg entscheiden, da die Entscheidungsfindung nicht von der Höhe des Geldes abhängt. Es hängt davon ab, wie viel Rechenleistung sie benötigen, um neue Blöcke zu bilden.

Proof-of-Stake (PoS) 

Überblick: 
Implementierung: (Zukünftig) Ethereum, Peercoin, Decred
Vorteile: Energie Effizient
Nachteile: Potentiell „Nothing-at-Stake-Problem“, Deflation
Eignung: für Public, permissionless Blockchains

Der PoS ist eine vorgeschlagene Alternative zum Proof-of-Work für den Einsatz bei public Blockchains.
Eine Gruppe von Validatoren schlägt abwechselnd den nächsten Block vor und stimmt darüber ab, ob dieser der Blockchain angefügt werden soll. Das Gewicht der Stimmen jedes Validators hängt von der Höhe seiner Einzahlung (d.h. seines Einsatzes/Stake) ab.
Wesentliche Vorteile von PoS sind Sicherheit, reduziertes Zentralisierungsrisiko und Energieeffizienz.
Im Allgemeinen sieht ein Proof of Stake-Algorithmus wie folgt aus: Die Blockchain folgt den Vorschlägen einer Reihe von Prüfern bzw. Validatoren und jeder, der die Basis-Kryptowährung der Blockchain besitzt kann ein Prüfer werden, indem er eine spezielle Art von Transaktion sendet, die seinen Einsatz sperrt. Der Prozess der Erstellung von neuen Blöcken erfolgt dann anhand von pseudo-zufälligen Rechteverteilungen. Für die Validierung der einzelnen Blöcke müssen „Stimmen“ von anderen Validatoren gesammelt werden, wobei ein bestimmtes Quorum sowie eine bestimmte Quote erreicht werden müssen. Es gibt andere Möglichkeiten, an dem Proof-of-Stake teilzunehmen. Wenn der Stake-Betrag zu hoch ist, kannst du einem Pool beitreten und dadurch Gewinne erzielen. Du kannst es auf zwei Arten tun.

Zuallererst kannst du deine Coins an einen anderen Benutzer ausleihen, der am Pool teilnimmt und dann den Gewinn mit dir teilt. Du musst jedoch eine zuverlässige Person zur Betragsaufteilung finden.

Eine andere Methode wäre, dem Pool selbst beizutreten. Auf diese Weise wird jeder, der an diesem Pool teilnimmt, den Gewinn basierend auf dem Einsatzbetrag teilen.

Delegated Proof-of-Stake (DPoS) 

Überblick:

Implementierung: Steemit, EOS, BitShares

Vorteile: Günstige Transaktionen; skalierbar; energieeffizient

Nachteile: Teilweise zentralisiert

DPoS ist das geistige Kind von Daniel Larimer und unterscheidet sich sehr von PoS. In DPoS stimmen die Token-Hodler nicht über die Gültigkeit der Blöcke selbst ab, sondern wählen die Delegierten, die die Validierung in ihrem Namen durchführen. In einem DPoS-System gibt es in der Regel zwischen 21 und 100 gewählte Delegierte. Die Delegierten werden periodisch gemischt und erhalten den Befehl, ihre Blöcke einzuliefern. Wenige Delegierte erlauben es ihnen, sich effizient zu organisieren und bestimmte Zeitfenster für jeden Delegierten zu schaffen, um ihren Block zu veröffentlichen. Wenn Delegierte ihre Blöcke ständig verpassen oder ungültige Transaktionen veröffentlichen, wählen die Staker sie aus und ersetzen sie durch einen besseren Delegierten.

In DPoS können Miner zusammenarbeiten, um Blöcke herzustellen, anstatt wie in PoW und PoS zu konkurrieren. Durch die teilweise Zentralisierung der Blockbildung ist DPoS in der Lage, höhere Größenordnungen schneller auszuführen als die meisten anderen Konsensverfahren. EOS ist die erste Blockchain mit Blockzeiten < 1 Sekunde! Etwas schneller als die 10-Minuten-Blockzeiten von Bitcoin oder 15 Sekunden bei Ethereum.

Proof-of-Elapsed-Time

Überblick: 
Implementierung: Hyperledger Sawtooh
Vorteile: Energie Effizient, „fair“
Nachteile: Kann nur auf Intel-Maschinen ausgeführt werden
Eignung: sowohl public als auch private Blockchains

Ursprünglich von Intel entwickelt, beruht dieser Ansatz auf der Erkenntnis, dass Proof-of-Work eine obligatorische, aber zufällige Wartezeit für die Wahl des „Leaders“ vorschreibt.
PoET Consensus führt den Warteschritt in einem vertrauenswürdigen Hardwaremodul, dem Intel Software Guard Extensions (SGX), aus. in vielen modernen Intel CPUs verfügbar sind diese verfügbar. Teilnehmer im Netzwerk nennt im Wesentlichen eine Enklave innerhalb von SGX, um eine zufällige Verzögerung zu erzeugen, entsprechend zu warten und sich dann zum „Leader“ zu erklären.
Für den Konsens innerhalb des Netzwerks und das anhängen von neuen Blöcken, erstellt die Plattform eine Bescheinigung, die von jedem Teilnehmer verwendet werden kann um zu überprüfen, ob der „Leader“ zum richtigen Ergebnis kam und die richtige Zufallszeit gewartet hat.
Unter der Annahme, dass das Hardware-Modul nicht untergraben werden kann, erzeugt dies die gleiche Art von Finalität und Sicherheit wie der Mining-Prozess in PoW Systemen.

Proof-of-Authority (PoA)

Überblick: 
Implementierung: POA Network, Kovan Testnet (Ethereum/ Parity Client)
Vorteile: Sehr performant
Nachteile: Zentralisiert, „Single Point of Failure“
Eignung: für Public permissioned als auch private Blockchain

Der PoA ermöglicht schnelle Transaktionsgeschwindigkeiten durch einen Konsensus Mechanismus, welcher darauf beruht, dass ein Validator seine Identität und damit seine Reputation einsetzt um einen Konsensus im Netzwerk herzustellen.
Mit PoA erhalten einzelne Teilnehmer im Netzwerk das Recht, Validatoren zu werden, so dass ein Anreiz besteht, die gewonnene Position zu behalten. Durch das Koppeln von Reputation an die Identität werden Validatoren dazu angehalten, den Transaktionsprozess aufrechtzuerhalten und dessen Korrektheit sicherzustellen, da sie ihre Identität nicht mit einer negativen Reputation verknüpfen möchten.

Proof-of-Weight (PoWeight)

Überblick: 

Implementierung: Algorand, Filecoin, Chia

Vorteile: Anpassbar; skalierbar

Nachteile: Incentivierung kann eine Herausforderung sein

Proof-of-Weight ist eine breite Klassifizierung von Konsensverfahren, die auf dem Algorand-Konsensusmodell basieren. Die allgemeine Idee ist, dass, wo in PoS, Ihr Prozentsatz der Token im Netzwerk Ihre Wahrscheinlichkeit der „Entdeckung“ des nächsten Blocks, in einem PoWeight-System, einige andere relativ gewichtete Wert verwendet wird. Konkretes Beispiel: Filecoins Proof-of-Spacetime wird auf die Anzahl der IPFS-Daten gewichtet, die Sie speichern. Andere Systeme könnten Gewichte für Dinge wie Proof-of-Reputation enthalten.

Raft

Überblick: 
Implementierung: R3 Corda, Quorum
Vorteile: Performant, mehr Sicherheit hinsichtlich Ausfällen, außerdem vereinfacht
diese Teil-Zentralisierung das Einspielen von Updates und Bugfixes enorm
Nachteile: Um die Frage zu beantworten, ist Raft für jede Situation zu vermeiden, in der eine dieser Aussagen nicht angenommen werden kann:

• Knoten haben Zugriff auf unbegrenzten persistenten Speicher, der nicht beschädigt werden kann, und jedes Schreiben in den persistenten Speicher wird vor dem Absturz beendet (bekannt als Write-Ahead-Protokollierung);
• Für die Verzögerung von Nachrichten existiert keine obere Grenze, und Knoten können mit beliebigen Geschwindigkeiten arbeiten;
• Byzantinische Fehler können nicht auftreten;
• Die Clustermitgliedschaft kann sich nicht dynamisch ändern.
• Die auf jedem Knoten laufenden Zustandsmaschinen starten alle im selben Zustand und reagieren deterministisch auf Client-Operationen.

Eignung: für Private, permissioned Blockchain

Raft erreicht den Konsens über einen gewählten „Leader“. Teilnehmer im Netzwerk sind entweder „Leader“ oder „Follower“, bzw. „Candidate“.
Der „Leader“ informiert die „Follower“ regelmäßig über seine Existenz, indem er eine Heartbeat-Nachricht sendet. Wenn keine Heartbeat-Nachricht empfangen wird, ändert einer oder mehrere „Follower“ ihren Status zum „Candidate“ und initiieren eine Wahl.
Der „Leader“ hat die volle Verantwortung für die Verwaltung und Validierung der zu verbreitenden Blöcke. Der „Leader“ akzeptiert Transaktionen und teilt den „Followers“ mit, wann es sicher ist, den State der Blockchain mit den zur Verfügung stehenden Daten upzudaten.

Byzantine Fault Tolerance (BFT) 

Überblick: 

Implementierung: Hyperledger, Stellar, Dispatch und Ripple

Vorteile: Hoher Durchsatz; geringe Kosten; skalierbar

Nachteile: Semi-trusted

Eignung: für Public, Private Blockchain

Es gibt dieses klassische Problem ist verteiltes Rechnen, das normalerweise mit byzantinischen Generälen erklärt wird. Das Problem ist, dass mehrere byzantinische Generäle und ihre jeweiligen Teile der byzantinischen Armee und haben eine Stadt umgeben. Sie müssen gemeinsam entscheiden, ob sie angreifen oder nicht. Wenn einige Generäle ohne die anderen angreifen, wird ihre Belagerung in einer Tragödie enden. Die Generäle sind in der Regel durch Distanz getrennt und müssen Nachrichten weitergeben, um zu kommunizieren. Mehrere Kryptowährungsprotokolle verwenden eine Version von BFT, um zu einem Konsens zu kommen, jedes mit seinen eigenen Vor- und Nachteilen:

Praktische byzantinische Fehlertoleranz (PBFT): Eine der ersten Lösungen für dieses Problem war die praktische byzantinische Fehlertoleranz. Derzeit im Einsatz bei Hyperledger Fabric, mit wenigen (< 20, danach werden die Dinge ein wenig) vorselektierte Generäle PBFT läuft unglaublich effizient. Vorteile: Hoher Transaktionsdurchsatz Nachteile: zentralisiert/genehmigt

Federated Byzantine Agreement (FBA): FBA ist eine weitere Klasse von Lösungen für das Problem der byzantinischen Generäle, die von Währungen wie Stellar und Ripple verwendet werden. Die allgemeine Idee (heh) ist, dass jeder byzantinische General, der für seine eigene Kette verantwortlich ist, die Botschaften sortiert, während sie hereinkommen, um die Wahrheit festzustellen. In Ripple werden die Generäle (Validatoren) von der Ripple-Stiftung vorselektiert. In Stellar kann jeder ein Validator sein, also wählen Sie, welchen Validatoren Sie vertrauen können.

Directed Acyclic Graphs (DAGs)

Überblick: 

Implementierung: Iota, Hashgraph, Raiblocks/Nano

Vorteile: Netzwerk-Skalierbarkeit; geringe Kosten

Nachteile: Abhängig von der Umsetzung

Eignung: für Public, permissionless Blockchain

DAGs sind im Moment heißer als Vitaliks Tinder-Profil. DAGs sind eine Form des Konsenses, die die Blockchain-Datenstruktur nicht nutzt und Transaktionen meist asynchron abwickelt. Der große Profi ist theoretisch unendliche Transaktionen pro Sekunde, aber DAGs haben Stärken und Schwächen wie jeder andere Konsens.

Tangle: Tangle ist der von Iota verwendete DAG-Konsens-Algorithmus. Um eine Iota-Transaktion zu versenden, müssen Sie zwei vorherige Transaktionen, die Sie erhalten haben, bestätigen. Der Two-for-One, Pay-it-Forward-Konsens stärkt die Gültigkeit von Transaktionen, je mehr Transaktionen dem Tangle hinzugefügt werden. Da der Konsens durch die Transaktionen hergestellt wird, könnte theoretisch, wenn jemand 1/3 der Transaktionen generieren kann, er den Rest des Netzwerks davon überzeugen, dass ihre ungültigen Transaktionen gültig sind. Solange das Transaktionsvolumen nicht ausreicht, um 1/3 des Volumens zu erzeugen, wird Iota alle Transaktionen des Netzwerks auf einem zentralen Knoten namens „The Coordinator“ überprüfen. Iota sagt, dass der Coordinator wie Trainingsräder für das System funktioniert und entfernt wird, sobald das Tangle groß genug ist.

Hashgraph: Hashgraph ist ein von Leemon Baird entwickelter Klatschprotokoll-Konsens. Knoten teilen ihre bekannten Transaktionen nach dem Zufallsprinzip mit anderen Knoten, so dass schließlich alle Transaktionen zu allen Knoten geklatscht werden. Hashgraph ist wirklich schnell (über 250.000 Transaktionen pro Sekunde), aber nicht resistent gegen Sybil-Angriffe. Hashgraph ist also eine großartige Option für private Netzwerke, aber Sie werden es nicht bald in einem öffentlichen Netzwerk wie Ethereum oder Dispatch implementiert sehen.

Blockgitter: Nano (früher Raiblocks) läuft mit einer Drehung auf der Blockkette, die als Blockgitter bezeichnet wird. Das Blockgitter ist eine Struktur, in der jeder Benutzer (Adresse) seine eigene Kette bekommt, an die nur er schreiben kann, und jeder hat eine Kopie aller Ketten. Jede Transaktion wird sowohl in einen Sendeblock auf der Senderkette als auch in einen Empfangsblock auf der Kette des Empfängers aufgeteilt. Das Blockgitter scheint fast zu einfach zu funktionieren, aber es läuft bereits in der Wildnis. Die einzigartige Struktur lässt das Block-Gitter offen für einige einzigartige Angriffsvektoren wie den Penny-Spend-Angriff, bei dem Angreifer die Anzahl der Ketten aufblähen müssen, indem sie vernachlässigbare Mengen an eine Vielzahl von leeren Brieftaschen schicken.

SPECTRE: Serialisierung von Proof-of-Work-Ereignissen: Transaktionsbestätigung über
Recursive Elections, besser bekannt als SPECTRE, ist eine vorgeschlagene Bitcoin-Skalierungslösung, die eine Kombination aus PoW und DAGs verwendet, um einen skalierbaren Konsens zu erreichen. In SPECTRE werden die Blöcke nicht nur auf einen, sondern auf mehrere Elternteile abgebaut, so dass das Netzwerk potenziell mehrere Blöcke pro Sekunde verarbeiten kann. Das Mining eines Blocks, der auf einige übergeordnete Blöcke zeigt, unterstützt die Gültigkeit dieser Blöcke. Im Vergleich zu den „längsten Kettengewinnen“ von PoW verwendet SPECTRE so etwas wie „Blöcke mit dem meisten Kindergewinn“. SPECTRE wurde noch nicht in der Wildnis getestet, und es werden wahrscheinlich neue Angriffsvektoren auftauchen, aber es fühlt sich wie eine sehr clevere Möglichkeit an, Bitcoin zu reparieren.

Federated Consensus

Überblick: 
Implementierung: Chain, BTL
Vorteile: Sehr performant
Nachteile: …
Eignung: für Private, permissioned Blockchain

Federated Consensus ist ein einfacher Konsensus Algorithmus, bei dem bestimmte Teilnehmer im Netzwerk zu Validatoren ernannt werden.
Sie erzeugen und signieren neue Blöcke wenn bestimmte Validierungsanforderungen, die durch meist konfigurierbare Parameter definiert sind, erfüllt werden.
Bevor ein Block an das gesamte Netzwerk gesendet wird, muss der Validator, welcher den Block erzeugt hat, den Block zuerst an alle übrigen Validatoren senden, so dass der Block durch eine vorab bestimmte Anazhl von Validatoren signiert werden kann, bevor das gesamte Netzwerk den Block als gültig akzeptiert.
Da das Signieren von Blöcken im Vergleich zum Proof of Work ein rechnerisch günstiger Vorgang ist, können Blöcke mit hoher Geschwindigkeit erstellt werden.
Weiters wird oft eine konfigurierbare Blockperiode zwischen zwei Blöcken angegeben, so dass Validatoren erst dann versuchen, einen Block zu erzeugen, wenn diese Zeitspanne verstrichen ist.

Im Kontext von Blockchains und Distributed Ledger Technology lassen sich daraus drei Kriterien ableiten, welche ein Protokoll/Mechanismus/Algorithmus simultan erfüllen muss um oben genanntes Problem lösen bzw. mitigieren zu können:

• Crash-Toleranz: Für den Fall, dass Teile des Netzwerks ausfallen, muss die Funktionalität eben dieses trotzdem sichergestellt sein.
• Byzantine-Fault-Toleranz: Falls sich gewisse Teile des Netzwerks nicht ordnungsgemäß verhalten, oder gar versuchen sollten die Regeln des Netzwerks zu untergraben, muss Sicherheit und Konsistenz des Netzwerks gewährleistet werden können.
• Valide Daten: Der Datenwert auf den sich die Teilnehmer im Netzwerk einigen, muss formal valide und nachvollziehbar (geordnet) sein.

Habe ich deinen Lieblingsalgorithmus verpasst? Feedback ist immer willkommen! Hoffentlich hast du die Lektüre dieses Leitfadens so hilfreich gefunden, wie ich es beim Schreiben gefunden habe.

🙏 Und vielen Dank an alle Blockchain-Builder da draußen, die uns das hier besorgt haben far❤

Quellen:

https://www.persistent.com/wp-content/uploads/2017/04/WP-Understanding-Blockchain-Consensus-Models.pdf

https://en.bitcoin.it/wiki/Proof_of_work

https://en.wikipedia.org/wiki/Consensus_(computer_science)

https://en.wikipedia.org/wiki/Raft_(computer_science)

https://www.adjoint.io/docs/consensus.html

https://en.wikipedia.org/wiki/Proof-of-authority

https://arxiv.org/abs/1707.01873

https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ