Hace un par de días, mientras me desplazaba por X, me encontré con una publicación sobre la red de pruebas DuskEVM, y un detalle llamó mi atención. El 10 de agosto, la red de pruebas DuskEVM salió en vivo; Solidity y Hardhat funcionaban sin problemas, pero Hedger, el motor principal del contrato confidencial, ha estado ejecutándose por separado en la red de pruebas Ethereum Sepolia desde noviembre de 2025. El equipo oficial aún no ha anunciado cuándo se fusionarán ambos.
Cuando la gente ve esta brecha de 9 meses, la primera reacción es preocupación. Una cadena enfocada en la privacidad que tenga su capa de privacidad y su capa EVM probadas por separado podría sonar inusual.
Pero después de revisar la documentación técnica, empecé a pensar que esta estrategia de pruebas en dos vías podría ser, en realidad, una elección subestimada en la arquitectura de Dusk. El stack de Dusk es por capas. #Dusk se encarga del settlement y la disponibilidad de datos, DuskEVM es la capa EVM, y Hedger es la capa de privacidad que usa cifrado homomórfico y pruebas de conocimiento cero.
Si las tres capas se probaran juntas, un error criptográfico y un error de contrato podrían volverse difíciles de distinguir. Probarlas por separado permite al equipo poner primero en marcha la capa EVM, dejar que los desarrolladores implementen aplicaciones, luego validar Hedger por separado en Sepolia y, finalmente, volver a fusionarlo en $DUSK . Esto hace que el proceso de depuración sea mucho más claro.
No estoy seguro de si este criterio es correcto. También es posible que, durante la fusión final, aparezcan conflictos de protocolo y se requiera rehacer trabajo previo. La modularidad suena bien, pero la ingeniería siempre conlleva costos de coordinación.
Pero desde otro ángulo, los clientes institucionales temen más que algo se rompa que que algo sea lento. Un despliegue por fases puede ser más confiable que intentar lanzar todo a la vez y luego tener que hacer un rollback.
Lanzar primero la EVM y fusionar Hedger después de una validación adecuada podría ser simplemente una forma de asegurarse de que la base sea sólida.
¿Qué opinan ustedes sobre esta estrategia de pruebas en dos vías? Quiero escuchar la opinión de todos.@Dusk
Cuando la gente ve esta brecha de 9 meses, la primera reacción es preocupación. Una cadena enfocada en la privacidad que tenga su capa de privacidad y su capa EVM probadas por separado podría sonar inusual.
Pero después de revisar la documentación técnica, empecé a pensar que esta estrategia de pruebas en dos vías podría ser, en realidad, una elección subestimada en la arquitectura de Dusk. El stack de Dusk es por capas. #Dusk se encarga del settlement y la disponibilidad de datos, DuskEVM es la capa EVM, y Hedger es la capa de privacidad que usa cifrado homomórfico y pruebas de conocimiento cero.
Si las tres capas se probaran juntas, un error criptográfico y un error de contrato podrían volverse difíciles de distinguir. Probarlas por separado permite al equipo poner primero en marcha la capa EVM, dejar que los desarrolladores implementen aplicaciones, luego validar Hedger por separado en Sepolia y, finalmente, volver a fusionarlo en $DUSK . Esto hace que el proceso de depuración sea mucho más claro.
No estoy seguro de si este criterio es correcto. También es posible que, durante la fusión final, aparezcan conflictos de protocolo y se requiera rehacer trabajo previo. La modularidad suena bien, pero la ingeniería siempre conlleva costos de coordinación.
Pero desde otro ángulo, los clientes institucionales temen más que algo se rompa que que algo sea lento. Un despliegue por fases puede ser más confiable que intentar lanzar todo a la vez y luego tener que hacer un rollback.
Lanzar primero la EVM y fusionar Hedger después de una validación adecuada podría ser simplemente una forma de asegurarse de que la base sea sólida.
¿Qué opinan ustedes sobre esta estrategia de pruebas en dos vías? Quiero escuchar la opinión de todos.@Dusk
