Lo que captó mi atención en la documentación de Dusk no es la capa de privacidad, sino lo pequeño que sigue siendo el átomo de transacción en una transacción L1.
El modelo de transacciones actual de Dusk incluye una sola acción opcional: una transferencia, un memo, una llamada de contrato, un despliegue o un blob. Un issue de Rusk de junio de 2026 propone transacciones en lote, porque las intenciones del usuario con múltiples pasos actualmente tienen que dividirse en transacciones separadas, cada una firmada de forma independiente y sujeta a inclusión.
Esto importa más para la infraestructura financiera de lo que suena.
Piensa en emisión → pago → entrega, o en una regla de liquidación de varias etapas. Si esos pasos están separados, el protocolo actualmente no garantiza que caigan juntos. Uno puede tener éxito mientras otro falla, dejando potencialmente un estado intermedio.
Hay un matiz importante: DuskVM admite llamadas entre contratos, así que la composición a nivel de aplicación ya es posible. La brecha que estoy observando es la atomicidad de las transacciones a nivel inferior, no si Dusk puede ejecutar contratos complejos.
Para mí, este es un intercambio interesante: Dusk impulsa las finanzas reguladas y programables, mientras que una de las primitivas centrales de transacción sigue siendo deliberadamente simple.
Me interesa saber si el “batching” nativo se convierte en parte del protocolo, o si Dusk mantiene esa complejidad dentro de contratos y capas de ejecución.
@Dusk $DUSK #dusk
El modelo de transacciones actual de Dusk incluye una sola acción opcional: una transferencia, un memo, una llamada de contrato, un despliegue o un blob. Un issue de Rusk de junio de 2026 propone transacciones en lote, porque las intenciones del usuario con múltiples pasos actualmente tienen que dividirse en transacciones separadas, cada una firmada de forma independiente y sujeta a inclusión.
Esto importa más para la infraestructura financiera de lo que suena.
Piensa en emisión → pago → entrega, o en una regla de liquidación de varias etapas. Si esos pasos están separados, el protocolo actualmente no garantiza que caigan juntos. Uno puede tener éxito mientras otro falla, dejando potencialmente un estado intermedio.
Hay un matiz importante: DuskVM admite llamadas entre contratos, así que la composición a nivel de aplicación ya es posible. La brecha que estoy observando es la atomicidad de las transacciones a nivel inferior, no si Dusk puede ejecutar contratos complejos.
Para mí, este es un intercambio interesante: Dusk impulsa las finanzas reguladas y programables, mientras que una de las primitivas centrales de transacción sigue siendo deliberadamente simple.
Me interesa saber si el “batching” nativo se convierte en parte del protocolo, o si Dusk mantiene esa complejidad dentro de contratos y capas de ejecución.
@Dusk $DUSK #dusk