Proof-Alternativen: Byzantinisches Problem, Delegierte und vertrauensvolle Systeme
Neben Proof-of-Work und Proof-of-Stake (die wir schon in unserem vorherigen Artikel behandelt haben) gibt es allerlei Abwandlungen und Mischformen. Die folgenden beiden Modelle versuchen über Delegierte, Zeugen und Sprecher vertrauensvolle Systeme zu erstellen:
Proof-Verfahren: Delegated Byzantine Fault Tolerance
Dieser von NEO verwendete Algorithmus kombiniert die Vorteile von Proof-of-Stake und den Lösungen des byzantinischen Problems. Es wird eine Anzahl von Delegierten definiert, die einen Konsens über eine Order des Speakers erreichen müssen. Obwohl sowohl die Delegierten als auch die Speaker unehrlich sein können, wird mit einer Konsensrate von 66,66% abgesichert, dass die Buchungen korrekt sind. Innerhalb einer festgesetzten Zeit sendet ein Consensus Node eine Transaktion mit den Signaturen des Senders an das gesamte Netzwerk. Der erste Speaker sieht sich die Buchung an und sendet seinen Vorschlag; dieser Vorschlag wird wiederum von den Delegierten validiert. Wenn die Delegierten zustimmen und den Bock signieren, wird der Block in die Blockchain gehängt. Wenn der Prozess die festgesetzte Zeit überschreitet, wird eine neue Konsensrunde gestartet.
Das byzantinische Problem
Warum reicht eine Konsensrate von 66,66%? Die Basis dafür ist das sogenannte byzantinische Problem.
Der Legende nach hatten osmanische Generäle im Jahr 1453 n. Chr. bei der Belagerung von Konstantinopel (Byzanz) ein Kommunikationsproblem. Während sie an verschiedenen Stellen um die Stadt lagerten und nur mit Boten kommunizieren konnten, wussten sie bei der Planung ihres Angriffs, dass einige der Generäle Verräter waren und bewusst die Planung torpedieren würden.
Im Jahre 1982 veröffentlichten Lamport, Shostak und Pease – entspannte 500 Jahre später – Lösungen für dieses Problem (hier ihre Publikation).
Grundannahmen dieser Lösung sind die Folgenden: Der Befehlshaber schickt allen Generälen den selben Befehl und die loyalen Generäle befolgen jeweils den Befehl, den sie erhalten. Alle schicken untereinander jeweils ebenfalls die Befehle, wobei bekannt ist, dass die illoyalen diese Befehle verfälschen und die loyalen nicht. Damit können die Leutnants die eingehenden Befehle als Wahl behandeln, also jenen Befehl ausführen, der ihnen am öftesten zugetragen wird.
Eine Lösung besagt, dass solange der Anteil der verräterischen Generäle kleiner als ein Drittel ist, die Lösung tolerant ist gegen den Byzantinischen Fehler.
Die zweite Lösung benötigt nicht fälschbare Signaturen; diese erhält Fehlertoleranz bei beliebiger Anzahl verräterischer Generäle.
Auf Basis diese Lösung reicht also eine Zustimmung von zwei Drittel der Speaker und Delegierten, die nicht fälschbaren Signaturen erhöhen die Fehlertoleranz.
Delegated Proof-of-Stake (DPoS)
DPoS versucht die Nachteile des Proof-of-Work und des Proof-of-Stake auszugleichen, indem ein Layer technologischer Demokratie eingezogen wird. Die Echtheit von Transaktionen wird von auserwählten Zeugen bestätigt. Diese Zeugen werden von den Eigentümern der Coins bestimmt. Es kann eine unbeschränkte Anzahl von Zeugen bestimmt werden, solange zumindest 50 % der Mitglieder der Meinung sind, dass mit den gewählten Zeugen ausreichend Dezentralisierung gewährleistet ist.
Zusätzlich werden auf die gleiche Art Delegierte gewählt, die dafür verantwortlich sind das Netzwerk zu erhalten und sogar Änderungen am Netzwerk vorschlagen können.
Damit soll nicht nur aktuelle Funktionalität und Sicherheit gewährleistet werden, sollten Änderungen notwendig werden, so können diese ebenfalls einfach abgestimmt werden.
