عندما كنت أضبط مؤشر Dusk، وقعت في حفرة: جعلت transaction ID وcontract ID يشتركان في دالة تجزئة واحدة. يتم استخدام SHA3-256 لـ block hash وMerkle root؛ وBLAKE3 لـ contract bytecode وevent bloom filter؛ وBLAKE2b لكلٍّ من contract ID وtransaction ID؛ وSHA2-256 لـ سلامة المحفظة وتوليد اشتقاق المفاتيح.

يشبه ذلك أختامًا لأرشيف من أربع قطع. ختم الإيداع وختم العقد وختم استلام الوثائق يمكنها جميعًا ضغط أرقام، لكن نظام التسجيل لا يتعرف إلا على ذلك الختم المحدد. إذا أخطأت اختيار الخوارزمية، فسيبدو الناتج كأنه تجزئة طبيعية، لكن العقد لن تجد الكائن الموافق. أما الحفرة الأخرى فهي إعادة تجزئة سلسلة العرض بالصيغة السداسية عشرية مرة أخرى؛ غالبًا ما تتوقع واجهات البروتوكول bytes الخام؛ إن الالتفاف عبر الترميز خطوة إضافية يغيّر كل شيء.

لذلك عند التكامل سأحتفظ بالبايتات الأصلية، وأولّد المعرفات باستخدام SDK الرسمي أو Rusk، ثم أختبر بمجموعات اختبار باستخدام block وtransaction وcontract المعروفة. وثائق Dusk أيضًا (@Dusk Dusk) توصي بتقليل تكرار تنفيذ ترميز البروتوكول. فصل المهام عبر خوارزميات متعددة يفرّق المسؤوليات كذلك، ويحوّل الأمور مثل الإصدارات وترتيب endianness وصيغة الإدخال إلى عناصر تحقق. مجرد توليد سلسلة بحجم/طول صحيح من الأحرف لا يعني إلا أن الدالة اكتملت؛ أما هوية السلسلة على الشبكة فلا بد من الرجوع والتأكد منها#dusk $DUSK