DUSKDS — ASENTAMIENTO Y DISPONIBILIDAD DE DATOS
Después de investigar DuskVM y DuskEVM, empecé a prestar atención a una parte que se menciona menos, pero que aun así es muy importante en la arquitectura de Dusk: DuskDS.
Si DuskEVM se centra en la ejecución, entonces DuskDS se encarga de secciones como el consenso, el asentamiento y la disponibilidad de datos.
Lo que me parece interesante es que Dusk no intenta meter todas las funciones en un mismo entorno de ejecución. Los componentes se separan para asumir tareas diferentes.
En el modelo de DuskEVM, la transacción se procesa en L2. El secuenciador introduce la transacción en el bloque y, después, el batched (batcher) envía los datos a DuskDS. A partir de ahí, los datos continúan pasando por el compromiso de estado (state commitment), las pruebas de fallos (fault proofs) y el asentamiento.
Un punto que me resulta fácil de confundir es pensar que, porque una transacción se haya incluido en un bloque, el asentamiento ya se ha completado. La ejecución y el asentamiento son dos pasos distintos.
En aplicaciones habituales, esta diferencia puede no ser tan notable. Pero si Dusk apunta a DeFi, a activos tokenizados y a aplicaciones financieras, el asentamiento se vuelve un componente muy importante.
La disponibilidad de datos también merece atención, ya que las partes necesitan acceder a los datos para verificar el estado y comprobar lo que ocurrió en la red.
Después de investigar DuskDS, empecé a mirar a Dusk de otra manera.
DuskEVM es donde ocurre la ejecución, mientras que DuskDS proporciona la capa de infraestructura para el consenso, la disponibilidad de datos y el asentamiento.
Para mí, esta es una parte que vale la pena explorar si se quiere entender Dusk desde la perspectiva de una blockchain enfocada en aplicaciones financieras.
@Dusk $DUSK
#dusk
Después de investigar DuskVM y DuskEVM, empecé a prestar atención a una parte que se menciona menos, pero que aun así es muy importante en la arquitectura de Dusk: DuskDS.
Si DuskEVM se centra en la ejecución, entonces DuskDS se encarga de secciones como el consenso, el asentamiento y la disponibilidad de datos.
Lo que me parece interesante es que Dusk no intenta meter todas las funciones en un mismo entorno de ejecución. Los componentes se separan para asumir tareas diferentes.
En el modelo de DuskEVM, la transacción se procesa en L2. El secuenciador introduce la transacción en el bloque y, después, el batched (batcher) envía los datos a DuskDS. A partir de ahí, los datos continúan pasando por el compromiso de estado (state commitment), las pruebas de fallos (fault proofs) y el asentamiento.
Un punto que me resulta fácil de confundir es pensar que, porque una transacción se haya incluido en un bloque, el asentamiento ya se ha completado. La ejecución y el asentamiento son dos pasos distintos.
En aplicaciones habituales, esta diferencia puede no ser tan notable. Pero si Dusk apunta a DeFi, a activos tokenizados y a aplicaciones financieras, el asentamiento se vuelve un componente muy importante.
La disponibilidad de datos también merece atención, ya que las partes necesitan acceder a los datos para verificar el estado y comprobar lo que ocurrió en la red.
Después de investigar DuskDS, empecé a mirar a Dusk de otra manera.
DuskEVM es donde ocurre la ejecución, mientras que DuskDS proporciona la capa de infraestructura para el consenso, la disponibilidad de datos y el asentamiento.
Para mí, esta es una parte que vale la pena explorar si se quiere entender Dusk desde la perspectiva de una blockchain enfocada en aplicaciones financieras.
@Dusk $DUSK
#dusk