Я, настраивая Dusk индекса́тор, наступил на одну проблему: заставил transaction ID и contract ID использовать одну и ту же хэш‑функцию. Хэш блока и Merkle root — SHA3-256; байткод контракта и фильтр bloom для событий — BLAKE3; contract ID и transaction ID — BLAKE2b; целостность кошелька и выведение ключей — SHA2-256.

Это похоже на четыре печати в архиве. Пломбирующая печать на поступивших документах, печать контракта и печать выдачи позволяют выдавить номер, но система учёта признаёт только ту, которая указана. Если выбрать алгоритм неверно, вывод всё равно выглядит как нормальный хэш — узлы же не смогут найти соответствующий объект. Ещё один подводный камень — повторно хэшировать строку с шестнадцатеричным представлением; протокольные интерфейсы обычно потребляют исходные байты. Кодирование усложняют на один лишний шаг — и всё меняется.

Поэтому при подключении я оставляю исходные байты: использую официальный SDK или генерирую ID в Rusk, а затем проверяю тестовыми векторами на известных блоках, транзакциях и контрактах. В документации @Dusk Dusk также советуют не дублировать лишний раз реализацию протокольного кодирования. Разделение обязанностей на разные алгоритмы помогает, а ещё делает обязательными для проверки версию, порядок байт и формат входных данных. Сгенерировать строку нужной длины — это лишь значит, что функция отработала; а онлайновую идентичность ещё нужно перепроверить и подтвердить, чтобы узнали соответствующий объект #dusk $DUSK