A cupboard with two drawers can look unnecessary until you realise you keep different things in each one. That’s how I’ve started thinking about Dusk’s Moonlight and Phoenix models.
Moonlight is the public, account-based side: balances and transfers are visible. Phoenix takes a different route, using shielded notes and zero-knowledge proofs so transaction details can remain private while the network still verifies that the rules were followed.
At first, having two models sounds like extra complexity. But that may actually be the point. Not every financial transaction needs the same level of visibility. Forcing everything into a transparent model exposes information that may be sensitive; forcing everything into a private model can make ordinary monitoring and integration harder.
Dusk seems to be accepting that these needs are genuinely different rather than pretending one design solves both. @Dusk $DUSK gives the network a way to support both public and shielded transfers on the same settlement layer.
The uncomfortable question is whether users will understand when to use which model. Flexibility is useful—but only if the complexity doesn’t become the new problem. #dusk
Moonlight is the public, account-based side: balances and transfers are visible. Phoenix takes a different route, using shielded notes and zero-knowledge proofs so transaction details can remain private while the network still verifies that the rules were followed.
At first, having two models sounds like extra complexity. But that may actually be the point. Not every financial transaction needs the same level of visibility. Forcing everything into a transparent model exposes information that may be sensitive; forcing everything into a private model can make ordinary monitoring and integration harder.
Dusk seems to be accepting that these needs are genuinely different rather than pretending one design solves both. @Dusk $DUSK gives the network a way to support both public and shielded transfers on the same settlement layer.
The uncomfortable question is whether users will understand when to use which model. Flexibility is useful—but only if the complexity doesn’t become the new problem. #dusk