En realidad, toda la pila @Dusk tiene dos libros contables relacionados pero distintos: uno es el libro de ejecución de DuskEVM, que hacia afuera presenta Ethereum JSON-RPC; el otro es el libro de liquidación de Dusk L1, que hacia afuera presenta GraphQL / RUES. DUSK debe leerse como el mismo número en ambos libros, pero su reloj, sus unidades y sus decimales no son iguales.
DuskEVM es una capa de ejecución EVM estilo OP Stack: devuelve bloques, logs y recibos con forma estándar de EVM; su liquidación final y la disponibilidad de datos se anclan luego a DuskDS mediante batchers, compromisos de estado y puenteado. Es decir, esto no es un adaptador de “traducir GraphQL en tiempo real a JSON-RPC”, sino que mantiene la consistencia final entre capas mediante el puente y los compromisos de estado. Lo realmente importante a tener en cuenta son los escenarios entre capas: la inclusión en DuskEVM es rápida, pero la liquidación completa y la confirmación del puente todavía requieren algunos pasos; durante ese tiempo, los estados que ve cada lado pueden diferir temporalmente.
El rol de $DUSK vuelve este riesgo más concreto. El lado nativo de L1 usa LUX; 1 DUSK equivale a 10 elevado a 9 LUX. DuskEVM, para ser compatible con el toolchain de Ethereum, expone DUSK con 18 decimales. Al puentear, si el cálculo o el manejo de la precisión se hace de forma incorrecta, un mismo valor podría no coincidir temporalmente entre los dos libros. Para una transferencia normal quizá sea solo un error de visualización; pero para una liquidación regulada, puede convertirse en una ventana de operación equivocada de “un lado muestra como acreditado y el otro aún no lo ha confirmado de forma final”.
Mi conclusión tras revisarlo es: evaluar #dusk ; no basta con mirar que “es compatible con EVM”, sino que hay que ver las garantías de consistencia entre el libro de liquidación de L1 y el libro de ejecución de EVM. La documentación, por ahora, no explica suficientemente la prioridad de fuentes de datos autorizadas, la detección de conflictos y los mecanismos de reparación; y DUSK es precisamente el número que no se puede leer mal en ninguno de estos dos libros. DYOR.
DuskEVM es una capa de ejecución EVM estilo OP Stack: devuelve bloques, logs y recibos con forma estándar de EVM; su liquidación final y la disponibilidad de datos se anclan luego a DuskDS mediante batchers, compromisos de estado y puenteado. Es decir, esto no es un adaptador de “traducir GraphQL en tiempo real a JSON-RPC”, sino que mantiene la consistencia final entre capas mediante el puente y los compromisos de estado. Lo realmente importante a tener en cuenta son los escenarios entre capas: la inclusión en DuskEVM es rápida, pero la liquidación completa y la confirmación del puente todavía requieren algunos pasos; durante ese tiempo, los estados que ve cada lado pueden diferir temporalmente.
El rol de $DUSK vuelve este riesgo más concreto. El lado nativo de L1 usa LUX; 1 DUSK equivale a 10 elevado a 9 LUX. DuskEVM, para ser compatible con el toolchain de Ethereum, expone DUSK con 18 decimales. Al puentear, si el cálculo o el manejo de la precisión se hace de forma incorrecta, un mismo valor podría no coincidir temporalmente entre los dos libros. Para una transferencia normal quizá sea solo un error de visualización; pero para una liquidación regulada, puede convertirse en una ventana de operación equivocada de “un lado muestra como acreditado y el otro aún no lo ha confirmado de forma final”.
Mi conclusión tras revisarlo es: evaluar #dusk ; no basta con mirar que “es compatible con EVM”, sino que hay que ver las garantías de consistencia entre el libro de liquidación de L1 y el libro de ejecución de EVM. La documentación, por ahora, no explica suficientemente la prioridad de fuentes de datos autorizadas, la detección de conflictos y los mecanismos de reparación; y DUSK es precisamente el número que no se puede leer mal en ninguno de estos dos libros. DYOR.
