Ich habe tatsächlich angefangen zu fragen, ob Dusk's zwei Transaktionsmodelle zu leicht gelobt werden.
Moonlight denkt wie Ethereum.
Du hast ein Konto, ein Guthaben und einen Nonce.
Phoenix denkt eher wie Bitcoin plus ZK.
Du hast Notes, Nullifier, einen Merkle-Baum und Beweise.
Dusk steckt beides in dasselbe Netzwerk.
Ich verstehe, warum.
Finanzinfrastruktur braucht nicht immer für jede Transaktion dasselbe Maß an Privatsphäre.
Aber hier ist der Teil, der mir unangenehm erscheint:
Zwei Modelle geben den Nutzern nicht nur Flexibilität. Sie geben Entwicklern auch zwei unterschiedliche mentale Modelle, über die sie nachdenken müssen.
In Moonlight prüft das Netzwerk direkt Guthaben und Kontostandzustand.
In Phoenix prüft das Netzwerk größtenteils, ob ein ZK-Beweis diese Eigenschaften beweist, ohne die zugrunde liegenden Daten offenzulegen.
Das ist kryptographisch elegant.
Aber Eleganz für das Protokoll bedeutet nicht automatisch Einfachheit für die Menschen, die darauf aufbauen.
Und genau hier denke ich, dass Dusk noch etwas beweisen muss.
Wenn regulierte Finanzwelt am Ende stark von beiden Modellen abhängt, müssen Entwickler nicht nur verstehen, welche Transaktion sie bauen, sondern auch, welches Zustandsmodell sie dafür verwenden sollten.
Vielleicht ist das ein Vorteil.
Vielleicht ist es unnötige Komplexität.
Ich glaube ehrlich gesagt, dass wir das noch nicht wissen.
Und deshalb finde ich das interessanter als den nächsten „Dusk hat Privatsphäre“-Beitrag.
Der eigentliche Test einer Architektur ist nicht, wie viele Funktionen sie hat. Es ist, wie viel Komplexität Entwickler von diesen Funktionen erben. wow interessant ...
@Dusk $DUSK #dusk
Moonlight denkt wie Ethereum.
Du hast ein Konto, ein Guthaben und einen Nonce.
Phoenix denkt eher wie Bitcoin plus ZK.
Du hast Notes, Nullifier, einen Merkle-Baum und Beweise.
Dusk steckt beides in dasselbe Netzwerk.
Ich verstehe, warum.
Finanzinfrastruktur braucht nicht immer für jede Transaktion dasselbe Maß an Privatsphäre.
Aber hier ist der Teil, der mir unangenehm erscheint:
Zwei Modelle geben den Nutzern nicht nur Flexibilität. Sie geben Entwicklern auch zwei unterschiedliche mentale Modelle, über die sie nachdenken müssen.
In Moonlight prüft das Netzwerk direkt Guthaben und Kontostandzustand.
In Phoenix prüft das Netzwerk größtenteils, ob ein ZK-Beweis diese Eigenschaften beweist, ohne die zugrunde liegenden Daten offenzulegen.
Das ist kryptographisch elegant.
Aber Eleganz für das Protokoll bedeutet nicht automatisch Einfachheit für die Menschen, die darauf aufbauen.
Und genau hier denke ich, dass Dusk noch etwas beweisen muss.
Wenn regulierte Finanzwelt am Ende stark von beiden Modellen abhängt, müssen Entwickler nicht nur verstehen, welche Transaktion sie bauen, sondern auch, welches Zustandsmodell sie dafür verwenden sollten.
Vielleicht ist das ein Vorteil.
Vielleicht ist es unnötige Komplexität.
Ich glaube ehrlich gesagt, dass wir das noch nicht wissen.
Und deshalb finde ich das interessanter als den nächsten „Dusk hat Privatsphäre“-Beitrag.
Der eigentliche Test einer Architektur ist nicht, wie viele Funktionen sie hat. Es ist, wie viel Komplexität Entwickler von diesen Funktionen erben. wow interessant ...
@Dusk $DUSK #dusk
