Antes pensaba que, cuando una cadena dice ser “compatible con EVM”, en realidad solo significaba ejecutar Solidity, permitir que las carteras se conectaran y listo, ya estaba. Pero, después de leer en serio el adaptador DuskEVM de @Dusk , en cambio siento que la parte más honesta de la compatibilidad es precisamente la de admitir primero que, en el fondo, ambos mundos no son compatibles. Le puse un nombre: “el paradójico de la compatibilidad”. Cuanto más se parezca a Ethereum por fuera, más tendrá que revelar por dentro esas diferencias.
A simple vista, DuskEVM efectivamente usa componentes OP que todos conocen—op-geth, op-node, op-batcher, op-proposer, op-challenger—, pero la liquidación que está debajo la hace Dusk, no Ethereum L1. Por eso en medio hace falta una “capa de traducción”: tomar el estado GraphQL / RUES de Dusk, convertirlo a JSON-RPC que entiendan las herramientas de Ethereum, y luego alimentar el mapeo de bloques, recibos, logs, almacenamiento y transacciones con la forma exacta que el otro lado espera. Esta tarea se parece muchísimo a la interpretación simultánea: no solo hay que traducir las palabras, sino también alinear el orden de las frases, las unidades y las referencias; si no, el interlocutor literalmente se va a perder.
#dusk
$DUSK también esconde un detalle en su papel: en L1 utiliza una unidad más pequeña, LUX, mientras que las herramientas de EVM asumen el mundo por WEI. El adaptador tiene que gestionar conversiones de unidades y además incorporar cómo Dusk identifica las llamadas a sus contratos de un modo diferente al de Ethereum. En otras palabras, DUSK es el combustible de la capa de ejecución, y es justamente lo que más necesita una traducción precisa entre ambos conjuntos de semánticas.
Me parece que aquí está lo verdaderamente difícil de la “compatibilidad”: no es simplemente soportar otro lenguaje de programación. Es traducir correctamente la determinación, el estado y la finalidad. Cuanto más fluido se vea por fuera, menos se puede fingir que los dos lados son iguales por dentro. Este “juntado” si se hace a medias, lo que el usuario verá como “normal” podría ser, en realidad, la ilusión más peligrosa de todas. Haz los deberes por tu cuenta; no solo me escuches a mí.
A simple vista, DuskEVM efectivamente usa componentes OP que todos conocen—op-geth, op-node, op-batcher, op-proposer, op-challenger—, pero la liquidación que está debajo la hace Dusk, no Ethereum L1. Por eso en medio hace falta una “capa de traducción”: tomar el estado GraphQL / RUES de Dusk, convertirlo a JSON-RPC que entiendan las herramientas de Ethereum, y luego alimentar el mapeo de bloques, recibos, logs, almacenamiento y transacciones con la forma exacta que el otro lado espera. Esta tarea se parece muchísimo a la interpretación simultánea: no solo hay que traducir las palabras, sino también alinear el orden de las frases, las unidades y las referencias; si no, el interlocutor literalmente se va a perder.
#dusk
$DUSK también esconde un detalle en su papel: en L1 utiliza una unidad más pequeña, LUX, mientras que las herramientas de EVM asumen el mundo por WEI. El adaptador tiene que gestionar conversiones de unidades y además incorporar cómo Dusk identifica las llamadas a sus contratos de un modo diferente al de Ethereum. En otras palabras, DUSK es el combustible de la capa de ejecución, y es justamente lo que más necesita una traducción precisa entre ambos conjuntos de semánticas.
Me parece que aquí está lo verdaderamente difícil de la “compatibilidad”: no es simplemente soportar otro lenguaje de programación. Es traducir correctamente la determinación, el estado y la finalidad. Cuanto más fluido se vea por fuera, menos se puede fingir que los dos lados son iguales por dentro. Este “juntado” si se hace a medias, lo que el usuario verá como “normal” podría ser, en realidad, la ilusión más peligrosa de todas. Haz los deberes por tu cuenta; no solo me escuches a mí.