Skip to content

Hashing Algorithms

This document provides an overview of the hashing algorithms used in Dusk, together with the information in which context and where they are used.

Blake3

  • Contract Bytecode Hash: To prevent malleability, a verification check is performed before deploying a contract. This ensures that the stored bytecode hash matches the contract’s actual bytecode. The hash is generated by hashing the entire bytecode of the contract using Blake3.
  • Contract Events Bloom Filter: Bloom filters are used to efficiently test the membership of events emitted by contracts. Blake3 is used as the hashing algorithm for our Bloom.

Blake2b

  • Contract ID: The contract ID of a smart contract is generated by hashing the contract bytecode, a unique nonce, and the contract owner with Blake2b.
  • “hash” Host Function: The abi host function hash computes a hash_to_scalar with Blake2b as its underlying hasher to hash a vector of bytes and then convert it to a BLS12-381 scalar.
  • Transaction ID: The ID of a transaction is a BLS12-381 scalar, that is generated through the hash_to_scalar function which uses Blake2b as its internal hasher. Both shielded and public transactions derive their respective Tx IDs from a Blake2b hash of their data, which is then converted into a BLS scalar.
  • Payload Hash of shielded transactions: A shielded transaction payload is hashed using the same hash_to_scalar. This scalar is used as an input to the zero knowledge circuit for verifying shielded transactions.
  • Hash Shielded Withdrawal: To create a signature for a shielded withdrawal, the message is hashed using hash_to_scalar, allowing the resulting BLS scalar to be signed with a shielded secret key.

SHA2-256

  • CRS Integrity Check: To verify the integrity of the Common Reference String (CRS) (prevent CRS Mismatch) a SHA-256 hash gets generated and compared with a correctly defined CRS hash constant.
  • Secret Key Derivation: SHA-256 is used for key derivation. In rng_with_index, a seed, key index, and a termination constant are hashed to produce a value that seeds a ChaCha12 CSPRNG. The resulting random value based on that hash seed is then used to generate the actual keys. The termination string ensures domain separation between public and shielded key pairs.

SHA3-256

  • Committee Creation for Consensus: In the consensus protocol, committees are created using an algorithm called deterministic sortition. First, a score is computed, and based on that score, eligible provisioners are selected. The score is computed using an SHA3-256 hash of some parameters of the consensus round.
  • Block Hash Computation: SHA3-256 is used to compute the hash of a block.
  • Merkle Roots: The merkle roots of the faults and transactions in a block are recorded in the block header for validation. Before their merkle roots are derived, all block transactions and faults are first hashed with SHA3-256.
  • Block Fault IDs: The ID of a block fault is its SHA3-256 hash.