© Excellent backgrounds/Shutterstock.com
Java Magazin
Konsensansätze für Blockchains

Auf der Suche nach Einigkeit

Die Hypeenergie beim Thema Blockchain ist gewaltig. Es ist auf jeden Fall zu empfehlen, sich vor dem Einsatz dieses Technologieansatzes sehr genau zu überlegen, ob man eine Lösung auf der Suche nach einem Problem vor sich hat oder andersherum. Dabei kann eine Reihe von Kriterien helfen, zu beurteilen, ob ein Distributed Ledger für einen vorliegenden Anwendungsfall tatsächlich angemessen ist. Eines der wichtigsten dieser Kriterien ist der Aspekt der Verteilung auf eine Vielzahl (oder zumindest eine Zahl > 1) von Rechnern (Knoten) und die Notwendigkeit, dass diese Knoten sich auf eine einzige konsistente Wahrheit einigen.

Stefan Tilkov


Das Problem ist nicht neu. Ein einziges Bit, das an mehr als einer Stelle gespeichert wird, kann gewaltige Kopfschmerzen verursachen, wenn man sicher sein will, dass alle Beteiligten sich zu jedem Zeitpunkt einig sind, ob es aktuell den Wert 1 oder 0 hat. Für eine redundante Speicherung von Daten gibt es eine Vielzahl von Gründen wie Ausfallsicherheit, Performanceoptimierung oder Offlineszenarien. Daher haben sich in der Informatik sowohl die Forschungsbereiche „verteilte Systeme“ als auch „Datenbanken“ seit vielen Jahrzehnten mit dem Thema auseinandergesetzt und Lösungsverfahren etabliert.

Klassische Konsensverfahren

Am bekanntesten sind wahrscheinlich Two-Phase-Commit, das von den relationalen Datenbanken mehr oder weniger gut unterstützt wird, und Paxos. Diese Verfahren sorgen mit mehr oder weniger hoher Sicherheit dafür, dass sich die Beteiligten auf eine Wahrheit einigen. In den letzten Jahren haben vor allem NoSQL-Datenbanken am CP-Ende des CAP-Theorems und Werkzeuge zum Management verteilter Systeme das Thema Konsens wieder ins Bewusstsein von Architekten und Entwicklern gerückt. Dabei sind vor allem Systeme erfolgreich und zuverlässig, die eine gemeinsame Weltsicht auf Basis wohlverstandener Algorithmen wie Raft (etcd), Zab (Zookeeper) oder Paxos mit seinen Varianten herstellen.

Eine Blockchain bzw. ein Distributed Ledger ist jedoch mehr als eine Datenbank. Der entscheidende Unterschied ist, dass man aus Sicht des Gesamtsystems den beteiligten Partnern – den Knoten oder Nodes – nicht vertrauen kann. Man muss davon ausgehen, dass jeder einzelne das System so zu manipulieren versucht, dass er einen Vorteil erhält. Eine solche Problemstellung bezeichnet man als byzantinisch, nach einem wissenschaftlichen Artikel [1], der sie anhand eines fiktiven Beispiels eines gemeinsamen Feldzugs byzantinischer Generäle erläutert, die sich weder darauf verlassen können, dass keiner den anderen verrät, noch den Nachrichten vertrauen können, die sie erhalten, weil sie unterwegs von Feinden verfälscht worden sein könnten.

Eine solche Situation ist sehr unangenehm und nicht trivial lösbar. Die lange Zeit bekannteste Lösung für das Problem ist der 1999 veröffentlichte PBFT-Algorithmus (Practical Byzantine Fault Tolerance) [2]. Ein auf dieser Basis implementiertes System toleriert bis zu 1/3 bösartiger (oder fehlerhafter) Akteure – eine respektable Leistung. Allerdings gibt es zwei Probleme: Zum einen setzt er voraus, dass die Gruppe der Knoten initial bekannt ist und kon...

Java Magazin
Konsensansätze für Blockchains

Auf der Suche nach Einigkeit

Die Hypeenergie beim Thema Blockchain ist gewaltig. Es ist auf jeden Fall zu empfehlen, sich vor dem Einsatz dieses Technologieansatzes sehr genau zu überlegen, ob man eine Lösung auf der Suche nach einem Problem vor sich hat oder andersherum. Dabei kann eine Reihe von Kriterien helfen, zu beurteilen, ob ein Distributed Ledger für einen vorliegenden Anwendungsfall tatsächlich angemessen ist. Eines der wichtigsten dieser Kriterien ist der Aspekt der Verteilung auf eine Vielzahl (oder zumindest eine Zahl > 1) von Rechnern (Knoten) und die Notwendigkeit, dass diese Knoten sich auf eine einzige konsistente Wahrheit einigen.

Stefan Tilkov


Das Problem ist nicht neu. Ein einziges Bit, das an mehr als einer Stelle gespeichert wird, kann gewaltige Kopfschmerzen verursachen, wenn man sicher sein will, dass alle Beteiligten sich zu jedem Zeitpunkt einig sind, ob es aktuell den Wert 1 oder 0 hat. Für eine redundante Speicherung von Daten gibt es eine Vielzahl von Gründen wie Ausfallsicherheit, Performanceoptimierung oder Offlineszenarien. Daher haben sich in der Informatik sowohl die Forschungsbereiche „verteilte Systeme“ als auch „Datenbanken“ seit vielen Jahrzehnten mit dem Thema auseinandergesetzt und Lösungsverfahren etabliert.

Klassische Konsensverfahren

Am bekanntesten sind wahrscheinlich Two-Phase-Commit, das von den relationalen Datenbanken mehr oder weniger gut unterstützt wird, und Paxos. Diese Verfahren sorgen mit mehr oder weniger hoher Sicherheit dafür, dass sich die Beteiligten auf eine Wahrheit einigen. In den letzten Jahren haben vor allem NoSQL-Datenbanken am CP-Ende des CAP-Theorems und Werkzeuge zum Management verteilter Systeme das Thema Konsens wieder ins Bewusstsein von Architekten und Entwicklern gerückt. Dabei sind vor allem Systeme erfolgreich und zuverlässig, die eine gemeinsame Weltsicht auf Basis wohlverstandener Algorithmen wie Raft (etcd), Zab (Zookeeper) oder Paxos mit seinen Varianten herstellen.

Eine Blockchain bzw. ein Distributed Ledger ist jedoch mehr als eine Datenbank. Der entscheidende Unterschied ist, dass man aus Sicht des Gesamtsystems den beteiligten Partnern – den Knoten oder Nodes – nicht vertrauen kann. Man muss davon ausgehen, dass jeder einzelne das System so zu manipulieren versucht, dass er einen Vorteil erhält. Eine solche Problemstellung bezeichnet man als byzantinisch, nach einem wissenschaftlichen Artikel [1], der sie anhand eines fiktiven Beispiels eines gemeinsamen Feldzugs byzantinischer Generäle erläutert, die sich weder darauf verlassen können, dass keiner den anderen verrät, noch den Nachrichten vertrauen können, die sie erhalten, weil sie unterwegs von Feinden verfälscht worden sein könnten.

Eine solche Situation ist sehr unangenehm und nicht trivial lösbar. Die lange Zeit bekannteste Lösung für das Problem ist der 1999 veröffentlichte PBFT-Algorithmus (Practical Byzantine Fault Tolerance) [2]. Ein auf dieser Basis implementiertes System toleriert bis zu 1/3 bösartiger (oder fehlerhafter) Akteure – eine respektable Leistung. Allerdings gibt es zwei Probleme: Zum einen setzt er voraus, dass die Gruppe der Knoten initial bekannt ist und kon...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang