#dusk La semana pasada, al montar localmente un nodo de prueba de DuskEVM y su script de despliegue, mi duda más central era la visibilidad de los datos de los slots de almacenamiento. En la arquitectura tradicional de Ethereum, el árbol de estado global es completamente transparente y consultable: mientras la máquina virtual siga la semántica estándar de EVM, los supuestos atributos “confidenciales” en la cadena no pueden activarse automáticamente; hace falta apoyarse en mecanismos de prueba adicionales para cubrir esa necesidad.
La arquitectura de doble carril de Dusk divide la red en distintos niveles: la parte de consenso y liquidación la gestiona de forma unificada el subsistema base DuskDS; el DuskVM nativo, apoyado en el protocolo Phoenix y en la especificación XSC, gestiona los activos confidenciales on-chain. Y el nuevo DuskEVM, simplemente, es una herramienta de ejecución que reduce el umbral de migración. Este enfoque modular, aunque evita el problema de reescribir código Rust, parte la lógica de seguridad que antes era integrada en dos sistemas distintos.$DUSK
La divergencia clave a nivel técnico está en la delimitación de responsabilidades. Si, al escribir la lógica de negocio en DuskEVM, el desarrollador debe invocar manualmente módulos externos como Citadel para ensamblar pruebas de conocimiento cero, entonces la carga de proteger la privacidad se desplaza de la capa de protocolo hacia el código de la aplicación. Si en la redacción de contratos inteligentes aparece incluso una pequeña omisión, los datos críticos de transacciones y posiciones siguen quedando expuestos en estado público.$BTC
Desde el ángulo de la ingeniería, adoptar Solidity sí permite captar desarrolladores rápidamente, pero también difumina los límites reales de los datos. Para el negocio patrimonial real orientado a instituciones, lo peor es tener reglas poco claras. La convivencia de dos entornos de ejecución, en lugar de ayudar, incrementa el costo de auditoría de llamadas a activos entre capas y amplía la superficie de ataque; por tanto, el desarrollador debe asumir por sí mismo el riesgo de cumplimiento.$ETH
Creo que, al ampliar la compatibilidad, la entidad oficial debería definir lo antes posible los estándares de mapeo de estado y sincronización de privacidad entre las dos capas: un simple compromiso técnico difícilmente convencerá de inmediato a un capital institucional riguroso. Cuando construyes aplicaciones confidenciales en la práctica, ¿te importa más la privacidad pura del WASM nativo o prefieres la conveniencia de desarrollo que aporta la capa de compatibilidad?@Dusk
La arquitectura de doble carril de Dusk divide la red en distintos niveles: la parte de consenso y liquidación la gestiona de forma unificada el subsistema base DuskDS; el DuskVM nativo, apoyado en el protocolo Phoenix y en la especificación XSC, gestiona los activos confidenciales on-chain. Y el nuevo DuskEVM, simplemente, es una herramienta de ejecución que reduce el umbral de migración. Este enfoque modular, aunque evita el problema de reescribir código Rust, parte la lógica de seguridad que antes era integrada en dos sistemas distintos.$DUSK
La divergencia clave a nivel técnico está en la delimitación de responsabilidades. Si, al escribir la lógica de negocio en DuskEVM, el desarrollador debe invocar manualmente módulos externos como Citadel para ensamblar pruebas de conocimiento cero, entonces la carga de proteger la privacidad se desplaza de la capa de protocolo hacia el código de la aplicación. Si en la redacción de contratos inteligentes aparece incluso una pequeña omisión, los datos críticos de transacciones y posiciones siguen quedando expuestos en estado público.$BTC
Desde el ángulo de la ingeniería, adoptar Solidity sí permite captar desarrolladores rápidamente, pero también difumina los límites reales de los datos. Para el negocio patrimonial real orientado a instituciones, lo peor es tener reglas poco claras. La convivencia de dos entornos de ejecución, en lugar de ayudar, incrementa el costo de auditoría de llamadas a activos entre capas y amplía la superficie de ataque; por tanto, el desarrollador debe asumir por sí mismo el riesgo de cumplimiento.$ETH
Creo que, al ampliar la compatibilidad, la entidad oficial debería definir lo antes posible los estándares de mapeo de estado y sincronización de privacidad entre las dos capas: un simple compromiso técnico difícilmente convencerá de inmediato a un capital institucional riguroso. Cuando construyes aplicaciones confidenciales en la práctica, ¿te importa más la privacidad pura del WASM nativo o prefieres la conveniencia de desarrollo que aporta la capa de compatibilidad?@Dusk