Ich schaue mir das Multi-Layer-Setup von Dusk wieder an, und der Teil, der mich am meisten stört, ist nicht, ob die Trennung von Ausführung und Abwicklung elegant ist. Vermutlich ist sie das. Die schwierigere Frage ist, was passiert, wenn diese Schichten nicht mehr perfekt synchron laufen.

DuskEVM kann die Ausführung übernehmen, während DuskDS näher an Abwicklung und Datenverfügbarkeit sitzt. Auf dem Papier ergibt die Trennung von Zuständigkeiten Sinn. Jede Schicht kann sich darauf konzentrieren, was sie am besten kann, statt alles in ein einziges System zu pressen.

Aber echte Märkte sind chaotisch.

Eine Transaktion kann ausgeführt werden, Daten können sich ausbreiten, die Abwicklung kann folgen, und irgendwo zwischen diesen Schritten führen Sie Timing, Abhängigkeiten, Wiederholungen ein—vielleicht sogar eine vorübergehende Uneinigkeit darüber, welcher Zustand tatsächlich endgültig ist. Genau dort fange ich an, weniger über Architektur nachzudenken und mehr über Abstimmung.

Jedenfalls von dem Standpunkt, den ich einnehme: Das Aufteilen der Schichten beseitigt die Komplexität nicht. Es verlagert die Komplexität in die Schnittstellen zwischen ihnen.

Das kann immer noch das bessere Design sein, aber dann werden die wichtigen Fragen andere. Wie schnell lösen sich Unstimmigkeiten auf? Was passiert während einer Überlastung? Welche Schicht wird zur maßgeblichen Quelle für die Wahrheit, wenn etwas mitten im Prozess fehlschlägt?

Ich bin mir noch nicht sicher, ob diese Trennung das operationelle Risiko wirklich reduziert oder es nur schwieriger sichtbar macht.

Vielleicht geht es bei der Architektur gar nicht darum, weniger Probleme zu haben.

Vielleicht geht es darum, festzulegen, wo die Probleme leben dürfen.
#dusk $DUSK @Dusk $ONG