Cuando ajusto el indexador de Dusk, caí en una trampa: hacer que el transaction ID y el contract ID compartan una misma función hash. El hash del bloque y el Merkle root usan SHA3-256; el bytecode del contrato y el filtro bloom de eventos usan BLAKE3; el contract ID y el transaction ID usan BLAKE2b; la integridad de la billetera y la derivación de claves usan SHA2-256.
Esto es como cuatro sellos distintos en un archivo. El sello de registro, el sello del contrato y el sello de recogida permiten estampar números, pero el sistema de registro solo reconoce el sello especificado. Si eliges mal el algoritmo, la salida sigue pareciendo un hash normal; sin embargo, los nodos no logran encontrar el objeto correspondiente. Otra trampa es volver a hashear la cadena de visualización hexadecimal: normalmente, las interfaces del protocolo consumen bytes originales; al dar una vuelta extra con la codificación, el resultado cambia por completo.
Por eso, al integrarme conservaré los bytes originales, generaré los IDs con el SDK oficial o con Rusk, y después haré vectores de prueba usando bloques, transacciones y contratos conocidos. La documentación @Dusk Dusk también sugiere evitar implementar repetidamente la codificación del protocolo. Separar funciones con varios algoritmos también convierte en requisitos verificables la versión, el orden de bytes y el formato de entrada. Que se pueda generar una cadena de longitud correcta solo indica que la función terminó; la identidad en la cadena aún debe confirmarse con una verificación inversa. #dusk $DUSK
Esto es como cuatro sellos distintos en un archivo. El sello de registro, el sello del contrato y el sello de recogida permiten estampar números, pero el sistema de registro solo reconoce el sello especificado. Si eliges mal el algoritmo, la salida sigue pareciendo un hash normal; sin embargo, los nodos no logran encontrar el objeto correspondiente. Otra trampa es volver a hashear la cadena de visualización hexadecimal: normalmente, las interfaces del protocolo consumen bytes originales; al dar una vuelta extra con la codificación, el resultado cambia por completo.
Por eso, al integrarme conservaré los bytes originales, generaré los IDs con el SDK oficial o con Rusk, y después haré vectores de prueba usando bloques, transacciones y contratos conocidos. La documentación @Dusk Dusk también sugiere evitar implementar repetidamente la codificación del protocolo. Separar funciones con varios algoritmos también convierte en requisitos verificables la versión, el orden de bytes y el formato de entrada. Que se pueda generar una cadena de longitud correcta solo indica que la función terminó; la identidad en la cadena aún debe confirmarse con una verificación inversa. #dusk $DUSK