Pensé que Citadel era solo otra capa de identidad.
Ya sabes, de ese tipo.
Conecta tu wallet, pasa las comprobaciones de cumplimiento, marca la casilla y sigue.
Pero cuanto más miraba cómo realmente se mueven las credenciales a través del sistema, menos me parecía que fuera una bóveda.
Se sentía más como un filtro.
En lugar de pedir a los usuarios que entreguen todos sus datos personales, el sistema puede centrarse en demostrar una afirmación específica sin convertir la información subyacente en la que se está pasando.
Ese cambio es bastante sutil, pero creo que importa.
La carga pasa de la divulgación a la atestación.
Y hay otra parte que me pareció interesante.
Una credencial no necesariamente es algo que conservas para siempre.
Su utilidad depende de si la afirmación sigue siendo válida.
Así, la verificación deja de tratarse tanto de recopilar datos de identidad y pasa a ser, más bien, de volver a demostrar repetidamente que aún cumples las condiciones requeridas.
Eso crea un tipo distinto de fricción.
Los usuarios no necesariamente se quedan porque el sistema sea conveniente.
Podrían quedarse porque iniciar el proceso de verificación en otro lugar tiene su propio costo.
Quizá esa sea la pregunta más grande sobre sistemas como Citadel.
¿La demanda realmente viene de personas que quieren más confianza y privacidad?
¿O viene del creciente costo de demostrar lo mismo otra vez en algún otro lugar?
Cuanto más miro DuskEVM, más pienso que la parte interesante no es simplemente que Dusk ahora sea compatible con EVM.
Es que los desarrolladores no tienen que desechar el flujo de trabajo que ya conocen.
Si estás construyendo con Solidity, Foundry, Hardhat, viem, ethers o con carteras EVM familiares, DuskEVM está diseñado para llevar esa experiencia al ecosistema de Dusk.
Pero la arquitectura subyacente es lo que llamó mi atención.
DuskEVM se encarga de la ejecución compatible con Ethereum, mientras que DuskDS proporciona la capa subyacente de consenso, liquidación y disponibilidad de datos.
DUSK se usa para la ejecución, y puede moverse entre Dusk L1 y DuskEVM mediante el puente.
También vale la pena entender la ruta de la transacción.
Una transacción llega al secuenciador de DuskEVM, se incluye en un bloque L2 y el batcher publica los datos de la transacción en DuskDS. Luego, las confirmaciones de estado y las pruebas de fallos conectan el estado resultante de vuelta a DuskDS para la liquidación.
Esa distinción importa.
La inclusión de una transacción no es automáticamente lo mismo que la liquidación final.
También me gusta que Dusk no esté obligando a cada desarrollador a entrar en un solo entorno.
Los desarrolladores de EVM pueden usar DuskEVM y sus herramientas existentes, mientras que quienes construyen contratos en Rust/WASM directamente para Dusk L1 pueden seguir usando DuskVM.
Así que mi conclusión es bastante simple:
DuskEVM no es interesante solo porque brinda compatibilidad con EVM a Dusk.
Es interesante porque ofrece a los desarrolladores un entorno de ejecución familiar, al tiempo que conecta ese entorno con la propia arquitectura de liquidación y disponibilidad de datos de Dusk.
Eso se siente como una historia mucho más grande que simplemente decir: “Dusk ya tiene un EVM”.