Después de estar demasiado tiempo en la cadena, me di cuenta de un detalle que es muy fácil de usar para engañar: cuanto más rápida es la confirmación de una transacción, más probable es que la gente confunda “ya entró en un bloque” con “el dinero ya llegó”. Yo le llamo la “paradoja de la inmutabilidad”.
El flujo de transacciones de DuskEVM lo explica bastante claro: la transacción primero se envía al sequencer, luego entra en un bloque de la red L2; después, el batcher publica los datos en DuskDS, y finalmente, mediante compromisos de estado y fault proofs, el resultado queda anclado de nuevo en la capa de liquidación. En otras palabras, que aparezca en un bloque es solo el primer paso; lo que realmente hace que la red se responsabilice por ese resultado son los pasos posteriores. La secuencia @Dusk se parece a un envío: generar el número de seguimiento no es lo mismo que haber recibido el paquete, y que el paquete se registre en almacén no significa que ya lo hayas abierto y verificado.
En el material incluso se advierte directamente que no uses “cuánto tiempo ha pasado” para inferir la inmutabilidad final, especialmente cuando necesitas transportar valor entre DuskEVM y L1.
$DUSK aquí cumple dos funciones a la vez: es el combustible que la capa de ejecución paga con gas, y también es el propio valor que se mueve de un lado a otro. Cuando el usuario ve que el saldo de DUSK cambia en cadena, tal vez solo sea un registro previo en la capa de ejecución; el puente y la liquidación todavía no se han completado. Así que, para quienes realizan transacciones o hacen consolidación de fondos, lo importante no es mirar el cronómetro, sino el estado del protocolo o el estado de la wallet.
Creo que ahí está lo verdaderamente difícil de este tipo de infraestructura de privacidad y cumplimiento: #dusk no solo debe ofrecer “rapidez”, sino también permitir que los usuarios distingan entre “está ocurriendo” y “ya está confirmado”. Si la capa de producto también difumina ese límite, los usuarios terminarán asumiendo riesgos de nivel de minutos dentro de interfaces de milisegundos. Haz tu tarea: no te quedes solo con lo que yo te diga.
El flujo de transacciones de DuskEVM lo explica bastante claro: la transacción primero se envía al sequencer, luego entra en un bloque de la red L2; después, el batcher publica los datos en DuskDS, y finalmente, mediante compromisos de estado y fault proofs, el resultado queda anclado de nuevo en la capa de liquidación. En otras palabras, que aparezca en un bloque es solo el primer paso; lo que realmente hace que la red se responsabilice por ese resultado son los pasos posteriores. La secuencia @Dusk se parece a un envío: generar el número de seguimiento no es lo mismo que haber recibido el paquete, y que el paquete se registre en almacén no significa que ya lo hayas abierto y verificado.
En el material incluso se advierte directamente que no uses “cuánto tiempo ha pasado” para inferir la inmutabilidad final, especialmente cuando necesitas transportar valor entre DuskEVM y L1.
$DUSK aquí cumple dos funciones a la vez: es el combustible que la capa de ejecución paga con gas, y también es el propio valor que se mueve de un lado a otro. Cuando el usuario ve que el saldo de DUSK cambia en cadena, tal vez solo sea un registro previo en la capa de ejecución; el puente y la liquidación todavía no se han completado. Así que, para quienes realizan transacciones o hacen consolidación de fondos, lo importante no es mirar el cronómetro, sino el estado del protocolo o el estado de la wallet.
Creo que ahí está lo verdaderamente difícil de este tipo de infraestructura de privacidad y cumplimiento: #dusk no solo debe ofrecer “rapidez”, sino también permitir que los usuarios distingan entre “está ocurriendo” y “ya está confirmado”. Si la capa de producto también difumina ese límite, los usuarios terminarán asumiendo riesgos de nivel de minutos dentro de interfaces de milisegundos. Haz tu tarea: no te quedes solo con lo que yo te diga.
