La arquitectura actual de Dusk tiene una característica muy evidente: “desmonta” deliberadamente.
A diferencia de la mayoría de las cadenas públicas, que meten el consenso, la ejecución y la liquidación en una sola pila monolítica, Dusk separa estas tres cosas. En la base está DuskDS, que gestiona el consenso, la disponibilidad de datos y la liquidación; en el medio cuelga un DuskEVM, totalmente compatible con Solidity, de modo que los desarrolladores que vienen desde Ethereum casi no necesitan cambiar código; y en la parte superior hay otra capa, DuskVM, dedicada a ejecutar aplicaciones nativas de privacidad. Las tres capas manejan su propia parte, conectadas con un mismo token DUSK.
Las motivaciones de esta elección no son difíciles de entender. Construir una cadena totalmente autosuficiente tiene como mayor coste que los desarrolladores deben aprender de nuevo la cadena de herramientas, por lo que el despegue del ecosistema sería muy lento. Al incorporar una capa EVM, Solidity, Hardhat y MetaMask —todo lo ya existente— se puede usar directamente, y la fricción para atraer desarrolladores baja de inmediato.
Pero el coste de esta elección también es muy directo: aumenta la complejidad, y el aumento ocurre justo donde más importa.
El flujo entre capas implica nuevos supuestos de confianza y superficies de ataque. El intercambio de activos entre DuskDS y DuskEVM requiere un puente nativo; aunque no es necesario encapsular activos ni usar custodios, el propio hecho de cruzar capas introduce etapas adicionales de verificación. En los últimos años, los incidentes derivados del diseño entre capas han sido mucho más numerosos que los originados por la propia máquina virtual.
También hay un problema que se suele pasar por alto: la distribución de los nodos. Dusk utiliza consenso SBA, que requiere que los nodos estén continuamente en línea y con la configuración correcta. Estos umbrales, aunque garantizan la seguridad de la red, también significan que los costes de hardware y operaciones para que un participante común ejecute nodos durante mucho tiempo no son bajos. Si los nodos se van concentrando poco a poco en manos de unos pocos grandes actores, incluso la mejor arquitectura acaba desvirtuándose.
Así que, al mirar Dusk ahora, el foco no está en cuántas capas tenga ni en su TPS. Me fijo en dos cosas: primero, si se ha explicado con claridad el estado de los activos y los límites de privacidad entre capas; y segundo, el tipo de aplicaciones que aparecen en la capa EVM: si todo son protocolos genéricos migrados, la modularidad solo cambia la forma de captar clientes; si en cambio hay aplicaciones que realmente llaman a capacidades secretas subyacentes (por ejemplo, un libro de órdenes cifrado usando Hedger o valores confidenciales según el estándar XSC), entonces sí queda demostrado que la diferenciación de esta arquitectura está siendo usada de forma real.
Ya está montada la arquitectura; ahora toca ver qué puede crecer por encima.
#dusk $DUSK @Dusk
A diferencia de la mayoría de las cadenas públicas, que meten el consenso, la ejecución y la liquidación en una sola pila monolítica, Dusk separa estas tres cosas. En la base está DuskDS, que gestiona el consenso, la disponibilidad de datos y la liquidación; en el medio cuelga un DuskEVM, totalmente compatible con Solidity, de modo que los desarrolladores que vienen desde Ethereum casi no necesitan cambiar código; y en la parte superior hay otra capa, DuskVM, dedicada a ejecutar aplicaciones nativas de privacidad. Las tres capas manejan su propia parte, conectadas con un mismo token DUSK.
Las motivaciones de esta elección no son difíciles de entender. Construir una cadena totalmente autosuficiente tiene como mayor coste que los desarrolladores deben aprender de nuevo la cadena de herramientas, por lo que el despegue del ecosistema sería muy lento. Al incorporar una capa EVM, Solidity, Hardhat y MetaMask —todo lo ya existente— se puede usar directamente, y la fricción para atraer desarrolladores baja de inmediato.
Pero el coste de esta elección también es muy directo: aumenta la complejidad, y el aumento ocurre justo donde más importa.
El flujo entre capas implica nuevos supuestos de confianza y superficies de ataque. El intercambio de activos entre DuskDS y DuskEVM requiere un puente nativo; aunque no es necesario encapsular activos ni usar custodios, el propio hecho de cruzar capas introduce etapas adicionales de verificación. En los últimos años, los incidentes derivados del diseño entre capas han sido mucho más numerosos que los originados por la propia máquina virtual.
También hay un problema que se suele pasar por alto: la distribución de los nodos. Dusk utiliza consenso SBA, que requiere que los nodos estén continuamente en línea y con la configuración correcta. Estos umbrales, aunque garantizan la seguridad de la red, también significan que los costes de hardware y operaciones para que un participante común ejecute nodos durante mucho tiempo no son bajos. Si los nodos se van concentrando poco a poco en manos de unos pocos grandes actores, incluso la mejor arquitectura acaba desvirtuándose.
Así que, al mirar Dusk ahora, el foco no está en cuántas capas tenga ni en su TPS. Me fijo en dos cosas: primero, si se ha explicado con claridad el estado de los activos y los límites de privacidad entre capas; y segundo, el tipo de aplicaciones que aparecen en la capa EVM: si todo son protocolos genéricos migrados, la modularidad solo cambia la forma de captar clientes; si en cambio hay aplicaciones que realmente llaman a capacidades secretas subyacentes (por ejemplo, un libro de órdenes cifrado usando Hedger o valores confidenciales según el estándar XSC), entonces sí queda demostrado que la diferenciación de esta arquitectura está siendo usada de forma real.
Ya está montada la arquitectura; ahora toca ver qué puede crecer por encima.
#dusk $DUSK @Dusk
