Saat saya mengutak-atik indeksator Dusk, saya pernah terjebak: membuat transaction ID dan contract ID memakai fungsi hash yang sama. Block hash dan Merkle root memakai SHA3-256; bytecode kontrak dan event bloom filter memakai BLAKE3; contract ID dan transaction ID memakai BLAKE2b; integritas wallet dan derivasi kunci memakai SHA2-256.

Ini seperti empat stempel di arsip. Stempel masuk, stempel kontrak, dan stempel pengambilan sama-sama bisa menghasilkan nomor, tetapi sistem registrasi hanya mengakui stempel yang ditentukan. Jika algoritmanya salah, keluarannya tetap tampak seperti hash normal, namun node tidak bisa menemukan objek yang sesuai. Jebakan lainnya adalah meng-hash lagi string tampilan heksadesimal; antarmuka protokol biasanya menerima bytes mentah. Jika encoding diputar satu langkah tambahan, hasilnya akan berubah total.

Karena itu, saat mengintegrasikan saya akan mempertahankan byte mentah, menggunakan SDK resmi atau Rusk untuk menghasilkan ID, lalu memakai block, transaction, dan contract yang sudah diketahui sebagai test vector. @Dusk Dusk juga merekomendasikan untuk mengurangi implementasi encoding protokol yang berulang. Berbagai algoritma memisahkan tanggung jawab, sekaligus menjadikan versi, urutan byte, dan format input sebagai item penerimaan. Bisa menghasilkan deretan karakter dengan panjang yang benar hanya berarti fungsinya sudah selesai berjalan; identitas on-chain tetap harus diverifikasi balik#dusk $DUSK