Vor ein paar Tagen ertappte ich mich dabei, über einen Aspekt der Blockchain-Performance nachzudenken, der selten diskutiert wird: Was passiert, wenn das Netzwerk nicht mehr davon ausgehen kann, dass alles normal funktioniert?
Die meisten Projekte sind leicht zu bewundern, wenn Validatoren online sind, Nachrichten sich bewegen und Blöcke genau wie erwartet produziert werden. Die schwierigere Frage lautet: Was geschieht, wenn ein großer Teil des Netzwerks plötzlich verschwindet?
Früher dachte ich, das sei einfach eine Frage des Abwartens, bis sich das System erholt. Doch nachdem ich mir Dusk genauer angesehen habe, wurde mir klar, dass der spannendere Teil ist, wie das Protokoll darauf ausgelegt ist zu reagieren, wenn der normale Betrieb zunehmend auseinanderbricht.
Das Konsensdesign von Dusk berücksichtigt eine eingeschränkte Beteiligung. Wenn eine nennenswerte Anzahl an Provisioners offline geht oder isoliert wird, nimmt das Protokoll nicht einfach an, dass der erwartete Validator-Set wie gewohnt weiterarbeitet. Wenn wiederholte Konsensiterationen das erforderliche Ergebnis nicht erreichen, verfügt das Protokoll über Mechanismen, die es ihm ermöglichen, sein Verhalten anzupassen und weiterhin die sich verändernden Bedingungen im Netzwerk zu bewältigen.
Diese Unterscheidung ist wichtiger, als es vielleicht klingt.
Eine Blockchain kann unter idealen Bedingungen außerordentlich gut funktionieren. Der wahre Test besteht darin, ob sie sinnvolle Entscheidungen treffen kann, wenn die Beteiligung sinkt, die Kommunikation unzuverlässig wird oder das erwartete Validator-Set nicht gebildet werden kann.
Aber es gibt eine weitere Frage, die ich genauso wichtig finde: Wie oft werden diese Wiederherstellungsmechanismen unter realistischen Bedingungen getestet?
Ein Protokoll kann auf dem Papier eine gut durchdachte Fail-Strategie haben, echter Vertrauensgewinn entsteht jedoch erst durch die Implementierung, durch Tests und durch die Beobachtung, wie sich das Netzwerk verhält, wenn tatsächlich etwas schiefgeht.
Deshalb denke ich, dass Blockchain-Resilienz nicht nur anhand von TPS oder Blockzeiten gemessen werden sollte. Der tiefere Test ist viel einfacher:
Wenn etwas kaputtgeht—weiß das Protokoll dann, wie es reagieren soll?
@Dusk #dusk $DUSK
$TUT $UAI
Die meisten Projekte sind leicht zu bewundern, wenn Validatoren online sind, Nachrichten sich bewegen und Blöcke genau wie erwartet produziert werden. Die schwierigere Frage lautet: Was geschieht, wenn ein großer Teil des Netzwerks plötzlich verschwindet?
Früher dachte ich, das sei einfach eine Frage des Abwartens, bis sich das System erholt. Doch nachdem ich mir Dusk genauer angesehen habe, wurde mir klar, dass der spannendere Teil ist, wie das Protokoll darauf ausgelegt ist zu reagieren, wenn der normale Betrieb zunehmend auseinanderbricht.
Das Konsensdesign von Dusk berücksichtigt eine eingeschränkte Beteiligung. Wenn eine nennenswerte Anzahl an Provisioners offline geht oder isoliert wird, nimmt das Protokoll nicht einfach an, dass der erwartete Validator-Set wie gewohnt weiterarbeitet. Wenn wiederholte Konsensiterationen das erforderliche Ergebnis nicht erreichen, verfügt das Protokoll über Mechanismen, die es ihm ermöglichen, sein Verhalten anzupassen und weiterhin die sich verändernden Bedingungen im Netzwerk zu bewältigen.
Diese Unterscheidung ist wichtiger, als es vielleicht klingt.
Eine Blockchain kann unter idealen Bedingungen außerordentlich gut funktionieren. Der wahre Test besteht darin, ob sie sinnvolle Entscheidungen treffen kann, wenn die Beteiligung sinkt, die Kommunikation unzuverlässig wird oder das erwartete Validator-Set nicht gebildet werden kann.
Aber es gibt eine weitere Frage, die ich genauso wichtig finde: Wie oft werden diese Wiederherstellungsmechanismen unter realistischen Bedingungen getestet?
Ein Protokoll kann auf dem Papier eine gut durchdachte Fail-Strategie haben, echter Vertrauensgewinn entsteht jedoch erst durch die Implementierung, durch Tests und durch die Beobachtung, wie sich das Netzwerk verhält, wenn tatsächlich etwas schiefgeht.
Deshalb denke ich, dass Blockchain-Resilienz nicht nur anhand von TPS oder Blockzeiten gemessen werden sollte. Der tiefere Test ist viel einfacher:
Wenn etwas kaputtgeht—weiß das Protokoll dann, wie es reagieren soll?
@Dusk #dusk $DUSK
$TUT $UAI
