There’s a detail that made me reread the Dusk architecture once more. At first, I thought DuskDS was simply the blockchain layer underneath DuskEVM, but the technical documentation describes it as something broader.
DuskDS is defined as the settlement and data availability layer of Dusk L1, responsible for consensus, finality, and the native transaction model. DuskEVM is the execution layer that uses DuskDS for settlement and data availability. DuskVM, on the other hand, executes contracts directly on Dusk L1.
I then dug deeper into how settlement is actually confirmed. DuskDS uses Succinct Attestation, a committee-based Proof-of-Stake mechanism. The process involves proposal, validation, and then ratification; once a block is ratified, finality is deterministic.
After that, I looked into the transaction model. Moonlight handles public accounts, while Phoenix uses shielded notes and zero-knowledge proofs. The two models are different, but in the end they both settle on the same chain.
Wait—this doesn’t mean DuskDS handles all application logic by itself. Execution still belongs to DuskVM or DuskEVM, but this is the part that changed how I see things: Dusk is separating execution rather clearly from settlement.
If so, the follow-up question is no longer whether DuskDS is the settlement layer, but rather: how will this settlement-splitting architecture make a real difference when financial applications start running at large scale?
#dusk $DUSK @Dusk
DuskDS is defined as the settlement and data availability layer of Dusk L1, responsible for consensus, finality, and the native transaction model. DuskEVM is the execution layer that uses DuskDS for settlement and data availability. DuskVM, on the other hand, executes contracts directly on Dusk L1.
I then dug deeper into how settlement is actually confirmed. DuskDS uses Succinct Attestation, a committee-based Proof-of-Stake mechanism. The process involves proposal, validation, and then ratification; once a block is ratified, finality is deterministic.
After that, I looked into the transaction model. Moonlight handles public accounts, while Phoenix uses shielded notes and zero-knowledge proofs. The two models are different, but in the end they both settle on the same chain.
Wait—this doesn’t mean DuskDS handles all application logic by itself. Execution still belongs to DuskVM or DuskEVM, but this is the part that changed how I see things: Dusk is separating execution rather clearly from settlement.
If so, the follow-up question is no longer whether DuskDS is the settlement layer, but rather: how will this settlement-splitting architecture make a real difference when financial applications start running at large scale?
#dusk $DUSK @Dusk
