Duskのインデックス作成で踏んだ落とし穴：transaction ID と contract ID を同じハッシュ関数で扱ってしまったこと。ブロックハッシュと Merkle root は SHA3-256；コントラクト bytecode と event bloom filter は BLAKE3；contract ID と transaction ID は BLAKE2b；ウォレットの完全性と鍵の派生には SHA2-256。

これは書庫の4つの印鑑みたいなもの。入庫印、契約印、受取印のどれも番号を押し出せるけれど、登録システムが認識するのは指定されたその1つだけ。アルゴリズムを間違えると、出力は普通のハッシュのように見えるのに、ノードは対応するオブジェクトを見つけられない。もう1つの落とし穴は、16進の表示文字列をさらに一度ハッシュしてしまうこと。プロトコルのインターフェースは通常、生のbytesを食べるので、エンコードの手順を1段余計に踏むと、結果がすべて変わってしまう。

なので接続時は元のバイト列を保持し、公式SDKやRuskでIDを生成し、既知のブロック、トランザクション、コントラクトを使ってテストベクターで確認する。@Dusk Dusk のドキュメントでも、プロトコルのエンコードを重複実装しないよう推奨している。複数のアルゴリズムで役割を分けるのは、バージョン、バイト順、入力形式を受け入れ条件（検収項目）として明確にすることにもつながる。桁数どおりの文字列が生成できても、関数が動いたことを示すだけで、オンチェーンの身元は再確認して照合する必要がある#dusk $DUSK