Ich habe immer wieder bemerkt, dass @Dusk nicht jede Transaktion zwangsläufig durch ein einziges Modell erzwingt.

Moonlight verwendet eine kontenbasierte Struktur, während Phoenix einen UTXO-Ansatz verfolgt. Anfangs wirkt das wie unnötige Komplexität. Warum zwei Arten der Darstellung von Transaktionen beibehalten, statt eine auszuwählen und die Architektur einfacher zu halten?

Je mehr ich darüber nachdachte, desto mehr ergab die Trennung für mich Sinn. Kontenbasiertes State ist unkompliziert für Salden und Anwendungslogik. Phoenix gibt Dusk eine andere Transaktionsstruktur, die mehr datenschutzorientierte Abläufe unterstützen kann.

Diese Flexibilität ist nützlich.

Aber es gibt einen Zielkonflikt, den meiner Meinung nach nicht genug diskutiert wird. Jedes zusätzliche Transaktionsmodell fügt ein weiteres mentales Modell für Entwickler und Nutzer hinzu, das man verstehen muss. Die Architektur kann zwar leistungsfähiger werden, aber das Gesamtsystem wird dadurch schwerer nachvollziehbar.

Bringt es also tatsächlich etwas für Dusk, unterschiedliche Transaktionsmodelle zu haben – oder überwiegt die zusätzliche Komplexität irgendwann den Nutzen?

#dusk @Dusk $DUSK