#dusk $DUSK @Dusk Nunca he entendido del todo una cosa: Dusk tiene su propio entorno nativo de ejecución de contratos inteligentes, diseñado específicamente para ejecutar contratos escritos en Rust. Al mismo tiempo, ha desarrollado una capa de ejecución compatible con Ethereum, para que la gente pueda escribir contratos con el lenguaje que ya conoce. Mantener ambos entornos a la vez se siente como añadir una carga extra de mantenimiento; en esta ocasión, quiero esclarecer específicamente qué busca lograr con esa elección.
Después de consultar información, lo que entiendo es que en realidad se están atendiendo dos tipos de desarrolladores completamente diferentes. El entorno nativo está dirigido a equipos que están dispuestos a aprender Rust directamente y quieren acceder a las capacidades más profundas del protocolo (por ejemplo, manipular directamente ese conjunto de cuentas cifradas/ocultas). Ofrece más rendimiento y flexibilidad, pero también tiene una barrera de entrada más alta. En el mercado hay, por lo general, mucha menos gente que escribe contratos inteligentes en Rust que quienes escriben con los lenguajes de la plataforma de Ethereum.
La capa de compatibilidad con Ethereum, en cambio, apunta a algo muy distinto: el “stock” o la “base existente”. Afuera ya hay una gran cantidad de desarrolladores y una cadena de herramientas ya preparada alrededor del ecosistema de Ethereum. Si Dusk no ofrece una entrada compatible, esa gran masa de personas básicamente no estaría dispuesta a volver a aprender la toolchain desde cero para una cadena nueva; preferirán desarrollar en otros lugares más compatibles.
Al principio pensé que era un “querer abarcarlo todo”—intentar agradar a ambos lados a la vez, lo que puede llevar a no hacerlo bien en ninguno. Luego revisé las explicaciones oficiales sobre la función de esas dos capas y me di cuenta de que, en realidad, no pretendían que ambas tuvieran una equivalencia completa. La capa nativa está pensada para escenarios a nivel de protocolo que requieren una integración profunda con funciones de privacidad y de liquidación. La capa compatible con Ethereum se usa más bien para conectarse rápidamente con el ecosistema externo y con aplicaciones ya existentes. Con esa división del trabajo, no parece un “recrear la rueda” de forma redundante; más bien es como abrir puertas adecuadas para distintos tipos de necesidades, no hacer dos veces la misma cosa.
Sin embargo, tampoco encontré datos concretos sobre la distribución de desarrolladores, por ejemplo, qué proporción existe actualmente entre aplicaciones desplegadas que siguen la ruta nativa y las que siguen la ruta compatible con Ethereum. Por ahora no hay cifras que pueda verificar. Lo único que puedo decir es que la idea de diseño de la arquitectura tiene sentido, pero después de que se implemente, habrá que ver—según el número de aplicaciones desplegadas en el futuro—qué ruta termina utilizándose de verdad.
Después de consultar información, lo que entiendo es que en realidad se están atendiendo dos tipos de desarrolladores completamente diferentes. El entorno nativo está dirigido a equipos que están dispuestos a aprender Rust directamente y quieren acceder a las capacidades más profundas del protocolo (por ejemplo, manipular directamente ese conjunto de cuentas cifradas/ocultas). Ofrece más rendimiento y flexibilidad, pero también tiene una barrera de entrada más alta. En el mercado hay, por lo general, mucha menos gente que escribe contratos inteligentes en Rust que quienes escriben con los lenguajes de la plataforma de Ethereum.
La capa de compatibilidad con Ethereum, en cambio, apunta a algo muy distinto: el “stock” o la “base existente”. Afuera ya hay una gran cantidad de desarrolladores y una cadena de herramientas ya preparada alrededor del ecosistema de Ethereum. Si Dusk no ofrece una entrada compatible, esa gran masa de personas básicamente no estaría dispuesta a volver a aprender la toolchain desde cero para una cadena nueva; preferirán desarrollar en otros lugares más compatibles.
Al principio pensé que era un “querer abarcarlo todo”—intentar agradar a ambos lados a la vez, lo que puede llevar a no hacerlo bien en ninguno. Luego revisé las explicaciones oficiales sobre la función de esas dos capas y me di cuenta de que, en realidad, no pretendían que ambas tuvieran una equivalencia completa. La capa nativa está pensada para escenarios a nivel de protocolo que requieren una integración profunda con funciones de privacidad y de liquidación. La capa compatible con Ethereum se usa más bien para conectarse rápidamente con el ecosistema externo y con aplicaciones ya existentes. Con esa división del trabajo, no parece un “recrear la rueda” de forma redundante; más bien es como abrir puertas adecuadas para distintos tipos de necesidades, no hacer dos veces la misma cosa.
Sin embargo, tampoco encontré datos concretos sobre la distribución de desarrolladores, por ejemplo, qué proporción existe actualmente entre aplicaciones desplegadas que siguen la ruta nativa y las que siguen la ruta compatible con Ethereum. Por ahora no hay cifras que pueda verificar. Lo único que puedo decir es que la idea de diseño de la arquitectura tiene sentido, pero después de que se implemente, habrá que ver—según el número de aplicaciones desplegadas en el futuro—qué ruta termina utilizándose de verdad.