#dusk $DUSK @Dusk While reading the Boreas release notes, I stopped at one small change DUSK no longer prices SHA-256, Keccak and generic hashing as if every input costs the same.

A 32-byte hash and a multi-kilobyte hash call the same host query, but they do not demand equal work. Boreas adds size-based pricing for those three, while BLS multisig verification scales by key count. KZG verification and secp256k1 recovery are not described as input-length-priced. Asking which query is “most expensive” without fixing input length and key count is almost the wrong question.

The comparison is flat API-call pricing versus computation imposed on validators. DUSK moved closer to the second.

There is a complication. Boreas is fork-aware: historical execution keeps pre-fork semantics, while current contracts receive the new schedule. Equivalent computation can carry different gas by execution context necessary for replay, awkward for developers forecasting costs.

For DUSK, better gas accuracy should reduce underpriced cryptographic workloads and make execution more consistent across nodes. It does not prove successful state transitions became cheaper. Maybe they became more honestly priced, even when the number rises.

I’m still waiting for benchmark data by input bucket. Deterministic accounting is only convincing when charged gas tracks real CPU work.
@Dusk #dusk #Dusk