Muchos se quejan de que el EVM <0>#dusk </0> es “dar marcha atrás”, pero yo creo que precisamente es porque el equipo por fin se dio cuenta de algo: la compatibilidad no es un compromiso, es control de costos.
Construir un entorno de ejecución completamente nuevo desde cero quizá no sea inferior técnicamente a Ethereum, pero el precio es que toda la infraestructura tendrá que crecer de nuevo: las firmas de auditoría tienen que aprender un lenguaje nuevo para poder emitir informes, el equipo de carteras debe reescribir la lógica de las firmas, y el servicio de indexación debe adaptarse otra vez. Al final, esos costos se trasladan a las instituciones que están dispuestas a poner en la cadena, y cuando dichas instituciones eligen una tecnología, a menudo miran primero “si mi equipo actual puede pasar directamente a hacerlo” en vez de “qué tan elegante es el diseño de este lenguaje”.
@Dusk EVM tiene la parte inteligente de separar la capa de ejecución de las capacidades subyacentes: los desarrolladores siguen usando las herramientas familiares para desplegar contratos, pero si quieren, pueden llamar a las capacidades nativas de liquidación confidencial y validación de cumplimiento. Es como ofrecer una opción al desarrollador, no obligarlo a seguir un único camino. Los equipos que ya han tokenizado en Ethereum, en teoría, pueden evitar rehacer gran parte del código y conectar directamente la lógica de liquidación a una cadena pensada originalmente para escenarios regulados.
Pero no lo miraría con más respeto solo por este diseño. Añadir una capa de compatibilidad también añade supuestos de confianza: en comunicación entre capas, sincronización de estado y demás, los incidentes que históricamente han ocurrido no han sido menos que los fallos de seguridad de los contratos. El riesgo más realista es que, si la mayoría de los desarrolladores solo traslada los proyectos antiguos tal cual, buscando la comodidad del ecosistema EVM, entonces esa capacidad de diferenciación real—la liquidación confidencial—se queda al margen, y $DUSK EVM no sería muy diferente de una sidechain EVM ordinaria.
Así que no me importa demasiado el ruido de los números del despliegue de contratos; lo que quiero saber es cuántos de estos contratos realmente están usando módulos nativos de privacidad y cumplimiento. Si esa proporción no sube, la historia diferencial que cuenta DuskEVM se quedará solo como una opción, sin convertirse en un hecho.
Construir un entorno de ejecución completamente nuevo desde cero quizá no sea inferior técnicamente a Ethereum, pero el precio es que toda la infraestructura tendrá que crecer de nuevo: las firmas de auditoría tienen que aprender un lenguaje nuevo para poder emitir informes, el equipo de carteras debe reescribir la lógica de las firmas, y el servicio de indexación debe adaptarse otra vez. Al final, esos costos se trasladan a las instituciones que están dispuestas a poner en la cadena, y cuando dichas instituciones eligen una tecnología, a menudo miran primero “si mi equipo actual puede pasar directamente a hacerlo” en vez de “qué tan elegante es el diseño de este lenguaje”.
@Dusk EVM tiene la parte inteligente de separar la capa de ejecución de las capacidades subyacentes: los desarrolladores siguen usando las herramientas familiares para desplegar contratos, pero si quieren, pueden llamar a las capacidades nativas de liquidación confidencial y validación de cumplimiento. Es como ofrecer una opción al desarrollador, no obligarlo a seguir un único camino. Los equipos que ya han tokenizado en Ethereum, en teoría, pueden evitar rehacer gran parte del código y conectar directamente la lógica de liquidación a una cadena pensada originalmente para escenarios regulados.
Pero no lo miraría con más respeto solo por este diseño. Añadir una capa de compatibilidad también añade supuestos de confianza: en comunicación entre capas, sincronización de estado y demás, los incidentes que históricamente han ocurrido no han sido menos que los fallos de seguridad de los contratos. El riesgo más realista es que, si la mayoría de los desarrolladores solo traslada los proyectos antiguos tal cual, buscando la comodidad del ecosistema EVM, entonces esa capacidad de diferenciación real—la liquidación confidencial—se queda al margen, y $DUSK EVM no sería muy diferente de una sidechain EVM ordinaria.
Así que no me importa demasiado el ruido de los números del despliegue de contratos; lo que quiero saber es cuántos de estos contratos realmente están usando módulos nativos de privacidad y cumplimiento. Si esa proporción no sube, la historia diferencial que cuenta DuskEVM se quedará solo como una opción, sin convertirse en un hecho.