Seguí pensando en Dusk como otra cadena de bloques más, con la privacidad integrada.
Luego empecé a mirar con más detenimiento la arquitectura, y esa suposición se volvió difícil de sostener.
Una cosa que captó mi atención es la separación entre la capa de liquidación de Dusk y sus entornos de ejecución.
DuskDS se encarga del consenso subyacente, la finalidad y la disponibilidad de datos, mientras que la ejecución de contratos inteligentes puede ocurrir a través de distintos entornos, incluyendo DuskVM y DuskEVM.
Al principio, me pregunté por qué era necesaria esa separación. ¿No sería más sencillo tener todo en un único entorno de ejecución?
Pero entonces empecé a pensar en el mercado objetivo de Dusk.
Si la red está intentando dar soporte a aplicaciones financieras reguladas, la liquidación y la lógica de la aplicación no necesariamente tienen los mismos requisitos. La capa encargada de decidir en qué está de acuerdo la red puede necesitar garantías diferentes de las que ofrece el entorno en el que los desarrolladores realmente construyen aplicaciones.
Eso vuelve la arquitectura más interesante para mí.
Dusk no parece limitarse a intentar hacer privados los contratos inteligentes. Parece estar separando algunas de las responsabilidades que hay por debajo de ellos.
Pero todavía hay algo que quiero entender mejor.
¿Separar la liquidación de la ejecución le da a las aplicaciones reguladas más flexibilidad, o crea otra capa de complejidad con la que los desarrolladores eventualmente tendrán que lidiar?
Esa es la parte que voy a investigar a continuación.
$DUSK #dusk @Dusk
Luego empecé a mirar con más detenimiento la arquitectura, y esa suposición se volvió difícil de sostener.
Una cosa que captó mi atención es la separación entre la capa de liquidación de Dusk y sus entornos de ejecución.
DuskDS se encarga del consenso subyacente, la finalidad y la disponibilidad de datos, mientras que la ejecución de contratos inteligentes puede ocurrir a través de distintos entornos, incluyendo DuskVM y DuskEVM.
Al principio, me pregunté por qué era necesaria esa separación. ¿No sería más sencillo tener todo en un único entorno de ejecución?
Pero entonces empecé a pensar en el mercado objetivo de Dusk.
Si la red está intentando dar soporte a aplicaciones financieras reguladas, la liquidación y la lógica de la aplicación no necesariamente tienen los mismos requisitos. La capa encargada de decidir en qué está de acuerdo la red puede necesitar garantías diferentes de las que ofrece el entorno en el que los desarrolladores realmente construyen aplicaciones.
Eso vuelve la arquitectura más interesante para mí.
Dusk no parece limitarse a intentar hacer privados los contratos inteligentes. Parece estar separando algunas de las responsabilidades que hay por debajo de ellos.
Pero todavía hay algo que quiero entender mejor.
¿Separar la liquidación de la ejecución le da a las aplicaciones reguladas más flexibilidad, o crea otra capa de complejidad con la que los desarrolladores eventualmente tendrán que lidiar?
Esa es la parte que voy a investigar a continuación.
$DUSK #dusk @Dusk