Spike: costs of hashing

[ch1bo]

❄️ Indeed the formula s * slope + intercept where s = number of Word64 is used to calculate builtin hash function costs in the cost model

• Builtin cost model lists all three hashing functions as ModelOneArgument https://github.com/input-output-hk/plutus/blob/1efbb276ef1a10ca6961d0fd32e6141e9798bd11/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/BuiltinCostModel.hs#L111-L113
• runOneArgumentModel function shows a linear multiplication of s * slope + intercept with a single ExMemory argument
  https://github.com/input-output-hk/plutus/blob/1efbb276ef1a10ca6961d0fd32e6141e9798bd11/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/BuiltinCostModel.hs#L208-L223
• Via some not-so-sure (fancy haskell) steps, it seems that makeBuiltinMeaning does determine the ExMemory cost of the provided function's argument. For hashing it's always a BuiltinBytestring and thus the length of the Bytestring in 8-byte / 64bit words is s. https://github.com/input-output-hk/plutus/blob/1efbb276ef1a10ca6961d0fd32e6141e9798bd11/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/ExMemory.hs#L149-L150

❄️ Given the cost model parameters in mainnet-alonzo-genesis.json

"blake2b-cpu-arguments-intercept": 2477736,
"blake2b-cpu-arguments-slope": 29175,
"blake2b-memory-arguments": 4,
"sha2_256-cpu-arguments-intercept": 2477736,
"sha2_256-cpu-arguments-slope": 29175,
"sha2_256-memory-arguments": 4,
"sha3_256-cpu-arguments-intercept": 0,
"sha3_256-cpu-arguments-slope": 82363,
"sha3_256-memory-arguments": 4,

we expect

• memory costs to be constant ModelOneArgumentConstantCost == 4
• cpu costs with some number of words lengths (org-mode table)

|             | slope | intercept | s= |       1 |       8 |      64 |      512 |
|-------------+-------+-----------+----+---------+---------+---------+----------|
| blake2b_256 | 29175 |   2477736 |    | 2506911 | 2711136 | 4344936 | 17415336 |
| sha2_256    | 29175 |   2477736 |    | 2506911 | 2711136 | 4344936 | 17415336 |
| sha3_256    | 82363 |         0 |    |   82363 |  658904 | 5271232 | 42169856 |
#+TBLFM: @2$5..@4$8=@1*$2+$3

❄️ Add a Hash contract to hash a given datum using supported hashing algorithms

❄️ Add test to ContractSpec which calculates units for multiple bytes lengths and all algorithms

❄️ The observed execution unit (deltas) output of cabal test hydra-node --test-options '--match "Contract/Hash"'

show that memory usage is constant and somewhat confirms the expected cpu usage values with an additional offset between [-20k..-200k] and [-870k..-1M] units for SHA2 and SHA3 respectively. It seems like the baseline is not good enough or maybe there had been some tweaks on the cost model?

[ghost]

I am surprised by the fact plutus compiler does not balk at the lack of INLINABLE pragmas for the Hash validator. There's something I still don't understand here.

[ghost]

I would have moved this to a dedicated HashSpec module.

[KtorZ]

The approach looks fine, but the results look odd for SHA3 with a negative delta on the first cases? Could it be because of the equalsByteString in the validator which takes longer for short bytestring than hashing it and comparing a longer hash? (This makes no sense to me... but since the code for the baseline is slightly different than the code for hashes, then it may explain things..).

Note that, for the encoding spike, I ended up writing validator as \_ \arg \_ -> let _whatever = myComputation arg in True which still evaluates the computation because of the evaluator strictness. The baseline validator is then just \_ \_ \_ -> True.

[ch1bo]

The approach looks fine, but the results look odd for SHA3 with a negative delta on the first cases? Could it be because of the equalsByteString in the validator which takes longer for short bytestring than hashing it and comparing a longer hash? (This makes no sense to me... but since the code for the baseline is slightly different than the code for hashes, then it may explain things..).

Yes. That was also my guess.

Note that, for the encoding spike, I ended up writing validator as \_ \arg \_ -> let _whatever = myComputation arg in True which still evaluates the computation because of the evaluator strictness. The baseline validator is then just \_ \_ \_ -> True.

I tried this as well and it resulted in much more surprising results 😕

[KtorZ]

I tried this as well and it resulted in much more surprising results confused

o.O

[github-actions]

Unit Test Results

    5 files    68 suites   3m 40s ⏱️
191 tests 188 ✔️ 3 💤 0 ❌

Results for commit 917127f.