Hay un detalle que me hizo volver a leer la arquitectura de Dusk una vez más. Al principio pensé que DuskDS era simplemente la parte blockchain ubicada debajo de DuskEVM, pero la documentación técnica describe que es algo más amplio.
DuskDS se define como la capa de settlement y de disponibilidad de datos de Dusk L1, encargada del consenso, la finality y los modelos de transacciones nativas. DuskEVM es la capa de ejecución que utiliza DuskDS para el settlement y la disponibilidad de datos. DuskVM, en cambio, ejecuta contratos directamente sobre Dusk L1.
Me adentré más en cómo se valida realmente el settlement. DuskDS usa Succinct Attestation, un mecanismo Proof-of-Stake basado en comités. El proceso incluye proposal, validation y luego ratification; cuando el bloque se ratifica, la finality es determinista.
Después miré el modelo de transacciones. Moonlight procesa cuentas públicas, mientras que Phoenix usa shielded notes y zero knowledge proofs. Dos modelos distintos, pero al final ambos hacen settlement en la misma cadena.
Espera, esto no significa que DuskDS se encargue por sí sola de toda la lógica de la aplicación. La ejecución sigue correspondiendo a DuskVM o DuskEVM, pero justamente aquí fue donde cambié mi forma de ver las cosas: Dusk separa bastante claramente la ejecución del settlement.
Entonces, la pregunta que vale la pena seguir ya no es si DuskDS es o no una capa de settlement, sino: ¿de qué manera esta arquitectura de separación del settlement marcará una diferencia práctica cuando las aplicaciones financieras empiecen a funcionar a gran escala?
#dusk $DUSK @Dusk
DuskDS se define como la capa de settlement y de disponibilidad de datos de Dusk L1, encargada del consenso, la finality y los modelos de transacciones nativas. DuskEVM es la capa de ejecución que utiliza DuskDS para el settlement y la disponibilidad de datos. DuskVM, en cambio, ejecuta contratos directamente sobre Dusk L1.
Me adentré más en cómo se valida realmente el settlement. DuskDS usa Succinct Attestation, un mecanismo Proof-of-Stake basado en comités. El proceso incluye proposal, validation y luego ratification; cuando el bloque se ratifica, la finality es determinista.
Después miré el modelo de transacciones. Moonlight procesa cuentas públicas, mientras que Phoenix usa shielded notes y zero knowledge proofs. Dos modelos distintos, pero al final ambos hacen settlement en la misma cadena.
Espera, esto no significa que DuskDS se encargue por sí sola de toda la lógica de la aplicación. La ejecución sigue correspondiendo a DuskVM o DuskEVM, pero justamente aquí fue donde cambié mi forma de ver las cosas: Dusk separa bastante claramente la ejecución del settlement.
Entonces, la pregunta que vale la pena seguir ya no es si DuskDS es o no una capa de settlement, sino: ¿de qué manera esta arquitectura de separación del settlement marcará una diferencia práctica cuando las aplicaciones financieras empiecen a funcionar a gran escala?
#dusk $DUSK @Dusk
