Ao ajustar um indexador Dusk, passei por uma armadilha: fazer com que o transaction ID e o contract ID compartilhem uma mesma função hash. Hash de bloco e Merkle root usam SHA3-256; bytecode do contrato e filtro bloom de eventos usam BLAKE3; contract ID e transaction ID usam BLAKE2b; integridade da carteira e derivação de chaves usam SHA2-256.

Isso é como quatro carimbos de um arquivo. O carimbo de entrada, o carimbo do contrato e o carimbo de retirada conseguem pressionar números; porém, o sistema de registro só reconhece aquele carimbo específico. Se a escolha do algoritmo estiver errada, a saída ainda parece um hash normal, mas os nós não conseguem encontrar o objeto correspondente. Outra armadilha é pegar a string de exibição em hexadecimal e fazer hash novamente; as interfaces do protocolo normalmente recebem bytes originais. Adicionar mais uma etapa de codificação deixa tudo diferente.

Por isso, ao integrar, vou manter os bytes originais, gerar IDs com o SDK oficial ou com Rusk e usar vetores de teste baseados em blocos, transações e contratos conhecidos. A documentação @Dusk Dusk também recomenda evitar repetir a implementação da codificação do protocolo. Separar responsabilidades entre vários algoritmos também transforma itens como versão, endianess e formato de entrada em critérios de aceitação. Conseguir gerar uma sequência de caracteres com o tamanho correto só prova que a função rodou; a identidade na cadeia ainda precisa ser confirmada na consulta.#dusk $DUSK