Algo sobre la capa de adaptadores de DuskEVM me dio curiosidad esta semana y es mucho más interesante que el discurso estándar de “soportamos Solidity” con el que la mayoría de las cadenas EVM inician.

Aquí está el problema real. La cadena nativa de Dusk habla GraphQL y algo llamado RUES para eventos y estado. Las herramientas de Ethereum no tienen ni idea de qué es eso. Cada explorador, wallet e indexador espera bloques, recibos, logs y pruebas con una forma muy específica del “estilo Ethereum”. Así que algo tiene que colocarse entre el estado nativo de Dusk y esa forma esperada, y traducirlo correctamente cada vez. Un campo inconsistente y todo el stack aguas abajo se rompe silenciosamente sin que nadie se dé cuenta de inmediato.

Unas pocas discrepancias lo vuelven concreto. Dusk denomina el valor en LUX en la capa base, mientras que el tooling de EVM espera wei, así que cada respuesta RPC necesita una conversión real, no solo un cambio de etiqueta. Los depósitos que pasan de Dusk L1 a DuskEVM usan aliasing de direcciones tipo OP, porque no hay una forma nativa de identificar qué contrato activó realmente un bridge o una captura de valor, así que tx.origin necesita mensajería entre dominios para recuperar quién lo envió de verdad. Y como la liquidación se finaliza en DuskDS en lugar de Ethereum, los juegos de disputa y las pruebas de fallo tomadas del OP Stack tuvieron que reestructurarse alrededor del consenso propio de Dusk, en vez del de Ethereum.

Eso fue lo que me hizo “clic”. Forcar el OP Stack no es la parte difícil. El secuenciador y la producción de bloques permanecen reconocibles como op-geth. Pero la liquidación de pruebas y la semántica del valor tuvieron que reconstruirse en la capa nativa de Dusk. Decidir dónde se traza esa línea es el verdadero trabajo de ingeniería.

#dusk $DUSK @Dusk

$ETH