Asumí que, si quería hacer tres cosas en cadena—aprobar, intercambiar y luego apostar—, la cadena lo trataría como una sola acción que sucede o que no sucede. Un issue abierto en el propio repositorio de Rusk de Dusk dice que no funciona así hoy en día.
Una transacción de Dusk hoy en día lleva una única operación opcional: una llamada a un contrato, un despliegue o un memo, con un valor, un destinatario, un nonce y una firma. Así que aprobar, intercambiar y apostar se convierten en tres transacciones separadas, cada una incluida o descartada de forma independiente. El issue de Dusk lo afirma sin rodeos: no existe una garantía de atomicidad entre ellas. Haces land approve y swap pero no stake, y te quedas a medio camino, sin un rollback a nivel de protocolo.
El problema no es solo que los flujos de varios pasos pueden detenerse a la mitad. Corregir eso cambia quién tiene que absorber el costo de compatibilidad.
Un contrato batcher hace atómica toda la secuencia, porque una subllamada fallida revierte la transacción externa. Pero un contrato objetivo que verifique quién lo llama directamente vería el batcher, no tú, a menos que ese contrato ya esté escrito para mirar más allá del llamador inmediato. Una transacción por lotes a nivel de protocolo te mantiene como llamador en cada paso, pero no se envía sin un nuevo formato de transacción, cambios de consenso, un hard-fork y que cada SDK de billetera se ponga al día.
Agregar batching no elimina el tradeoff. Decide si la carga de compatibilidad recae en la autorización de la aplicación o en el stack del protocolo.
"Arreglar la atomicidad no elimina el tradeoff; decide dónde se mueve la carga de compatibilidad y el límite de confianza."
Lo que yo realmente querría observar: si Dusk elige el batcher a nivel de aplicación o la transacción a nivel de protocolo, y qué supuestos existentes de autorización obliga a cambiar esa elección a los desarrolladores.
#dusk $DUSK @Dusk
Una transacción de Dusk hoy en día lleva una única operación opcional: una llamada a un contrato, un despliegue o un memo, con un valor, un destinatario, un nonce y una firma. Así que aprobar, intercambiar y apostar se convierten en tres transacciones separadas, cada una incluida o descartada de forma independiente. El issue de Dusk lo afirma sin rodeos: no existe una garantía de atomicidad entre ellas. Haces land approve y swap pero no stake, y te quedas a medio camino, sin un rollback a nivel de protocolo.
El problema no es solo que los flujos de varios pasos pueden detenerse a la mitad. Corregir eso cambia quién tiene que absorber el costo de compatibilidad.
Un contrato batcher hace atómica toda la secuencia, porque una subllamada fallida revierte la transacción externa. Pero un contrato objetivo que verifique quién lo llama directamente vería el batcher, no tú, a menos que ese contrato ya esté escrito para mirar más allá del llamador inmediato. Una transacción por lotes a nivel de protocolo te mantiene como llamador en cada paso, pero no se envía sin un nuevo formato de transacción, cambios de consenso, un hard-fork y que cada SDK de billetera se ponga al día.
Agregar batching no elimina el tradeoff. Decide si la carga de compatibilidad recae en la autorización de la aplicación o en el stack del protocolo.
"Arreglar la atomicidad no elimina el tradeoff; decide dónde se mueve la carga de compatibilidad y el límite de confianza."
Lo que yo realmente querría observar: si Dusk elige el batcher a nivel de aplicación o la transacción a nivel de protocolo, y qué supuestos existentes de autorización obliga a cambiar esa elección a los desarrolladores.
#dusk $DUSK @Dusk
