El contrato puede estar bien y mi llamada de DuskVM aun así puede morir con dos caracteres.
Las entradas de DuskVM no se envían como JSON legible. Son bytes codificados con rkyv, y Forge usa el controlador de datos fuera de la cadena del contrato para convertir algo humano como 42 en los bytes que el contrato realmente espera.
La parte incómoda es la entrega. Forge me da ese valor codificado en hexadecimal con un prefijo 0x. Un SDK puede querer que se conserve ese prefijo. El argumento --fn-args de Rusk Wallet me exige que lo elimine.
Así que puedo probar la lógica del contrato, verificar el WASM, codificar el argumento correctamente y luego romper la llamada en vivo pasando exactamente los mismos bytes con la forma de transporte incorrecta.
Ese es el bug de integración que más protegería. No porque sea dramático, sino porque todo lo anterior parece saludable. La función existe. El esquema está bien. El valor es correcto. El fallo está en el límite entre el controlador de datos y el remitente.
Si estuviera construyendo una app de DuskVM, normalizaría los argumentos de la llamada una sola vez y probaría ese límite contra cada ruta de envío que soporte.
Nunca deberían ser dos caracteres la razón de que una acción válida de contrato se convierta en una transacción fallida para el usuario.
#dusk $DUSK @Dusk
Las entradas de DuskVM no se envían como JSON legible. Son bytes codificados con rkyv, y Forge usa el controlador de datos fuera de la cadena del contrato para convertir algo humano como 42 en los bytes que el contrato realmente espera.
La parte incómoda es la entrega. Forge me da ese valor codificado en hexadecimal con un prefijo 0x. Un SDK puede querer que se conserve ese prefijo. El argumento --fn-args de Rusk Wallet me exige que lo elimine.
Así que puedo probar la lógica del contrato, verificar el WASM, codificar el argumento correctamente y luego romper la llamada en vivo pasando exactamente los mismos bytes con la forma de transporte incorrecta.
Ese es el bug de integración que más protegería. No porque sea dramático, sino porque todo lo anterior parece saludable. La función existe. El esquema está bien. El valor es correcto. El fallo está en el límite entre el controlador de datos y el remitente.
Si estuviera construyendo una app de DuskVM, normalizaría los argumentos de la llamada una sola vez y probaría ese límite contra cada ruta de envío que soporte.
Nunca deberían ser dos caracteres la razón de que una acción válida de contrato se convierta en una transacción fallida para el usuario.
#dusk $DUSK @Dusk