Ich habe auf ein kleines architektonisches Detail in Dusk geachtet, das mehr aussagt, als es auf den ersten Blick scheint: Der Transfer Contract fungiert als einziger Einstiegspunkt für sowohl öffentliches als auch für abgeschirmtes DUSK, statt zwei getrennte Systeme zu betreiben, die gelegentlich miteinander kommunizieren. Jede Überweisung, öffentlich oder abgeschirmt, und jede Umwandlung zwischen den beiden, läuft über dieselbe Contract-Logik. Das ist eine bewusste Designentscheidung, keine zufällige. Warum das wichtig ist, ist subtil. Zersplitterte Systeme erzeugen eher Randfälle, in denen sich Datenschutzgarantien oder Abrechnungen des Gleichgewichts unbemerkt auseinanderentwickeln können. Ein einziger Einstiegspunkt verringert die Angriffsfläche und macht das Auditieren der Logik zumindest theoretisch besser handhabbar. Was ich noch nicht weiß, ist, wie gut das unter echter Last standhält oder ob das Vereinigen des Pfads eigene Engpässe einführt, sobald die Nutzung wächst. Ich würde es lieber anhand des tatsächlichen Transaktionsvolumens testen sehen als nur anhand von Dokumentation. Die Frage ist, ob das Design sauber bleibt, wenn weitere Vertragstypen darauf aufbauen. Ich beobachte, wie es sich schlägt, sobald echter Durchsatz ankommt.
@Dusk #dusk $DUSK