[über]
[lösungen]
[log]
Nichts Passendes dabei? Stellen Sie ein, welche Inhalte Sie auf aleri.de sehen möchten:
Blockchain Konsens-Mechanismen in der Übersicht
Bitcoin ist bekannt, doch nur selten wird dem grundlegenden Konsens-Mechanismus, Proof-of-Work, weitere Beachtung geschenkt. Darüber hinaus gibt es noch zahlreiche andere Konsens-Mechanismen, welchen wir uns in diesem Post nähern wollen.
Was versteht man unter einer Blockchain?
Eine Blockchain kann aus hoher Flughöhe als ein „in einem Netzwerk verteilter Register“ bezeichnet werden. Daten liegen in dieser Datenbank in Blöcken vor, welche aneinander angeschlossen und kryptographisch versiegelt werden. Es entsteht eine Kette aus Blöcken - die Blockchain. Daten, die einmal in eine Blockchain geschrieben wurden, gelten als unveränderlich („immutable“). Neue Blöcke integrieren die kryptografische Signatur ihres Vorgängers in die eigenen Daten, so dass Manipulationen an einer vorgelagerten Stelle unmittelbar auffallen und korrigiert werden können.
Das sinnvolle Anwendungsszenario von Blockchain beginnt, wenn
- es keine zentrale Autorität gibt, der alle Beteiligten vertrauen (können) oder
- die zentrale Einheit praktischen Gründen im Wege steht.
Ausdruck des Ersteren ist das mangelnde Vertrauen gegenüber Unbekannten. Um im Finanz-Kontext zu sprechen: Man würde ja auch keinem Fremden ohne weiteren Vertrag einfach Geld in die Hand drücken und gehen, in der Hoffnung es beim nächsten Treffen wiederzubekommen.
Beim zweiten Punkt kommt die Disintermediation, der Wegfall eines Mittelsmannes (hier Banken) mit ins Spiel. Um diese Eigenschaft herum ist ein großer Hype entstanden, bspw. in der Energiewirtschaft.
Wie wird von einer Blockchain „Vertrauen aus dem Nichts“ geschaffen?
Die Algorithmen sind so ausgestaltet, dass die Hürde für die Übernahme des Netzwerkes immens hoch ist. Darüber hinaus sind aufgrund von vorherrschenden Regeln alle Teilnehmenden ähnlich einflussreich. Das Vertrauen stammt also vom Glauben in den Algorithmus. Ergänzend wird Vertrauen über regelbasierte Verträge (Smart Contracts) verstärkt. Letztere versichern die Übertragung von Daten, Rechten oder Währungseinheiten. Die den Smart Contracts zugrundeliegenden Daten sind "einsehbar" in der Blockchain gespeichert und können somit als Beweis fungieren.
Soweit sind die Mechanismen meist bekannt. Wie bei vielen Technologien gilt ab hier: Der erste Hype ist vorüber, aber es fehlen passende Projekte, weil das Problemfeld sehr dünn erscheint. Im Unternehmenskontext wäre bei mangelndem Vertrauen auch ein Joint-Venture mit gleich verteilten Unternehmensbeteiligungen eine valide Alternativlösung um den Einsatz einer Blockchain zu vermeiden und stattdessen auf eine herkömmliche Datenbanklösungen zu setzen.
Die Hürde im Kopf
Die Herausforderung besteht darin, Vertrauen in einer nicht-vertrauenswürdigen Umgebung zu schaffen. Dazu benötigt man u. a. Algorithmen, welche auch unter widrigen Vertrauensbedingungen eine Einigung unter allen Beteiligten schaffen sollen - die Konsens-Mechanismen.
Wir werden zwei Mechanismus-Gattungen genauer mit deren Untergruppen betrachten. Es geht an der Stelle nicht um bestimmte Ausgestaltungen bzw. Produkte wie Bitcoin oder Ethereum, sondern um generelle Unterschiede zwischen beweisbasierten Mechanismen („Proof-Of-X“) sowie Mechanismen, die auf Abstimmungen beruhen ("Vote-based").
1) Proof-based Consensus
- Proof-of-Work ist durch Bitcoin bekannt geworden. Es basiert darauf, mit Glück und massivem Ressourceneinsatz ein schweres mathematisches Rätsel zu lösen. Derjenige, der es als erster löst, darf die offenen Transaktionen zu einem Block schmieden, diesen Block der Blockchain anhängen und erhält eine Belohnung – vergleichbar mit einem Goldgräber (Mining). Das Glück verhält sich linear zu den Versuchen/Berechnungen. Kurz: Je mehr Leistung in das Mining-System gegeben wird, desto wahrscheinlicher ist es eine Belohnung zu erhalten. Aus diesem Grund gibt es Teilnehmende, die sich zusammenschließen, um jedes Rätsel gemeinsam zu lösen - sogenannte Mining-Pools. Dennoch führt das Gesamtsystem zu einer immer größeren Leistungsaufnahme. Ein Rennen gegen alle anderen und eine „Verschwendung von Ressourcen bzw. Energie".
- Proof-of-Stake versucht dieses Rennen zu bändigen, indem nur diejenigen schürfen dürfen, die mindestens einen definierten Anteil am Kuchen halten und auch bereit sind, diesen Anteil "aufs Spiel zu setzen". Weniger Teilnehmer sollen also zu einer geringeren Gesamt-Rechenleistung führen.
- Proof-of-Authority führt diesen Ansatz fort und lässt bewusst nur wenige Stakeholder schreiben. Hierbei werden wenige Teilnehmende aus allen per Wahlverfahren ausgewählt. Diese bilden vorübergehend den privilegierten Kreis derjenigen die schürfen dürfen. Wenn dabei gegen Regeln verstoßen wird, werden sie durch unterlassene Wiederwahl bestraft.
- Die Round Robin (Reihum-) Methode bringt die Idee der minimalen Goldgräber auf die Spitze. Es darf nur noch ein vorher bestimmter Teilnehmer schreiben. Der Aufwand des Schürfens bricht sich auf ein Minimum herunter. Hier besteht allerdings die Gefahr, dass das Netzwerk einfriert, falls ausgerechnet dieser Teilnehmer unerreichbar ist.
- Proof-of-Elapsed-Time hat einen anderen Ansatz: Alle Teilnehmenden müssen eine bestimmte Hardware besitzen die besonders genaue Zeitmessung unterstützt. Es werden Zufallswerte generiert und der, mit dem geringsten Wert darf schreiben, sobald die entsprechende Zeit vorüber ist.
- Proof-of-Excellence/-Effort/-Play ist im Vergleich zu den obigen Proof-Of-Mechanismen eher ein experimentelles Konstrukt. Statt Rechenleistung im Backend werden Interaktionen in den Effektiven Daten bewertet. Ist hinter diesen viel Anstrengung im vergangenen Zeitintervall zu vermuten, ist dem Teilnehmer das System auch viel wert. Er wird über das Schreibrecht belohnt.
2) Vote based Consensus
Im Practical Byzantine Fault Tolerance Mechanismus wird für jeden Block einzeln abgestimmt, nacheinander.
Im Ripple Modell definiert jeder Teilnehmende eine Liste von vertrauenswürdigen Teilnehmern. Es entspricht Proof-Of-Authority, lässt aber das Schreiben direkt zu, da nicht mehrere, sondern nur einer das Recht erhält, zu schreiben.
Man merkt, dass die Aufzählung spätestens hier unübersichtlich wird. Dabei gibt es noch viele weitere Algorithmen: Proof-of-Burn, Proof-of-Capacity, Proof-of-Sequential Work, Proof-of-Storage, Proof-of-WorkOrKnowledge, Proof-of-ZeroKnowledge und und und ...
Doch welche Charakteristika sind bei der Auswahl generell zu beachten?
Zum einen stellt sich die Frage nach der Motivation, welche die Teilnehmer mitbringen, um in einem Blockchain Netzwerk zu partizipieren.
Ist diese extrinsisch, geleitet von Belohnungen (z. B. Kryptowährung) oder ist sie intrinsisch, geführt von den Daten und dem Informationsaustausch? Bei extrinsisch geleiteter Motivation bieten sich Kryptowährungen und somit Proof-Of-Mechanismen an. Bei intrinsischer Motivation, bspw. dem Interesse an dem System selbst, ist dies aber nicht nötig und es können (auch) die anderen Mechanismen benutzt werden. Es gilt generell: Sobald der kollektive Glaube an das System verloren geht, gehen die Daten verloren.
Eine andere Herangehensweise wäre die vermutete Anzahl der Teilnehmenden und der Datendurchsatz.
Proof-of-Work gilt als träge. Die Schwere der mathematischen Rätsel wird bewusst laufend an die Rechenleistung des Netzwerks angepasst, um Race-Conditions zu vermeiden. Hier sind abstimmungsbasierte Vorgehensweisen klar im Vorteil. Dies ändert sich allerdings mit steigenden Teilnehmerzahlen. Ist der (mathematische) Beweis gelungen, schweigen die anderen Teilnehmer in Proof-of-Mechanismen. Dem hingegen muss/soll jeder Teilnehmer in abstimmungsbasierten Mechanismen seinen Senf dazugeben – dies macht abstimmungsbasierte Netzwerke langsam.
Gibt es denn besondere Krux, welche den Datendurchsatz behindert? Warum können die mathematischen Rätsel nicht 'einfacher gestaltet' werden um den Datendurchsatz zu erhöhen?
Die Antwort liegt in der Umwandlung eines Zero-Trust-Szenarios unter den Beteiligten hin zu einem Szenario bei dem alle an einem Strang ziehen. Das Schreckensszenario eines solchen Systems ist die Übernahme durch eine Teilmenge des Netzwerkes, vergleichsweise zu einer Geiselnahme von digitalen Gütern. Falls dieser Worst Case eintritt, können die restlichen Knoten keine Änderungen mehr bewirken. Im Falle einer Kryptowährung könnte die dominierende Gruppe jegliche unliebsamen Transaktionen (buy/trade/sell) unterbinden. Im Falle von Smart Contracts könnten diese Gruppe die Auslösung von Smart Contracts verhindern, weil die Aufnahme der auslösenden Trigger-Events in die Blockchain absichtlich nicht durchgeführt werden.
Um dies zu verhindern, wurde die Metrik der (Byztantinischen) Fehlertoleranz definiert als die Schwelle, ab der ein Blockchain-Netzwerk 'kippen' kann. Bezüglich Fehlertoleranz gilt, je höher die byztantinische Toleranzschwelle, desto mehr Teilnehmer müssen zustimmen bzw. desto teurer wird der Konsens. Es ist entsprechend wichtig, für den Einsatzzweck den richtigen Algorithmus auszuwählen. Darüber hinaus bilden diese nun genannten Möglichkeiten nur die Spitze des Eisbergs - es ist viel Bewegung in der Konzeption neuer Konsens-Mechanismen und -Konzepte.
Letztlich muss das Problem des gegenseitigen Vertrauens im Kopf behalten werden, welches den Anstoßpunkt für diese Lösungen bereithält.