Ich habe darüber nachgedacht, was passiert, wenn eine Transaktion in Dusk ankommt.

Zuerst fühlt es sich so an, als gäbe es nur eine Frage:

**„Soll das Netzwerk diese Transaktion akzeptieren?“**

Doch bei genauerem Hinsehen gibt es tatsächlich zwei verschiedene Fragen.

Erstens: Hält sich die Transaktion an die Regeln des Protokolls?

Dann, vorausgesetzt, das ist der Fall: Stimmen die Teilnehmenden über den Zustand überein, der daraus resultiert?

Diese Unterscheidung ist leicht zu übersehen, weil von außen beide Schritte zum gleichen Ergebnis führen: einem akzeptierten Zustand.

Aber architektonisch sind das unterschiedliche Aufgaben.

Wenn etwas schiefgeht, macht es die Trennung einfacher herauszufinden, was tatsächlich fehlgeschlagen ist. War die Transaktion ungültig? Oder war sie gültig, aber die Teilnehmenden waren sich über den resultierenden Zustand uneinig?

Ich finde, diese Trennung ist eine starke Designentscheidung.

Aber sie wirft auch eine neue Frage auf.

Jede Grenze zwischen Verantwortlichkeiten ist ein weiterer Übergabepunkt. Und jede Übergabe muss sich korrekt verhalten, wenn etwas Unerwartetes passiert.

Also komme ich immer wieder zu dieser Überlegung:

**Wird Dusk durch die Trennung von Gültigkeit und Konsens leichter unter Ausfällen zu durchdenken, oder schafft jede zusätzliche Grenze eine weitere Stelle, an der das System kaputtgehen kann?**

#Dusk @Dusk $DUSK