CIP-0043 | New Plutus Core built-in dataHash
#222
Conversation
There was a problem hiding this comment.
As one of the authors of the proposed CIP-36 (#218) which this would want to replace, I left some comments on where we (Hydra) would need additional specification analogous to our PR.
We were considering this approach as well (or even a much more specific to Hydra variant), but we felt that sha3_256 . serialiseBuiltinData (or a different hash algorithm of choice) is straight-forward to write, does not add any additional cost, is more flexible and does not increase the scope of CIP-36 unnecessarily.
| ## Abstract | ||
|
|
||
| We propose adding a new built-in `dataHash` for calculating the hash of `Data` on-chain, | ||
| in such a way that it is coherent with `txInfoData`. |
There was a problem hiding this comment.
In order to consider this as a replacement for #218, we would require quite some additional specification on how the builtinData is actually serialized before it is hashed. Mere "in such a way that it is coherent with txInfoData" is not sufficient for our use case.
There was a problem hiding this comment.
Can you explain this? How is this not sufficient?
| can access by having the concrete `Data` be passed in the redeemer (whether it's a minting policy | ||
| or validator). | ||
|
|
||
| It is also possible to verify signatures of (hashes of) `Data` with this built-in. |
There was a problem hiding this comment.
This would require having the same implementation of dataHash off-chain to produce the signature or a sufficiently detailed specification on how the Data is serialized (and hashed) such that the system creating the signature can follow the spec.
There was a problem hiding this comment.
We do already have a corresponding off-chain dataHash that is also coherent wrt. txInfoData.
| Hashing using a different algorithm isn't something you need in practice, | ||
| because no existing protocol hashes Plutus's `Data` with something other | ||
| than `blake2b_256`. If in a future version of Plutus the hashing algorithm | ||
| were to be changed, then `dataHash` would also be changed accordingly. |
There was a problem hiding this comment.
While this may be true for the Data provided by the ledger, it is not necessarily true for "user-supplied" Data. Furthermore, using a different hashing algorithm than blake2b_256 is not unrealistic. For example, in Hydra we are using sha2_256 right now! Although we could pick the used hash algorithm ourselves in our use case, other situations where some specific hashing scheme might be dictated by other, off-chain systems are perfectly thinkable and would not be able to use this builtin.
There was a problem hiding this comment.
I am not sure what you mean. You are saying that users could want to choose a different hashing algorithm, but without specifying a reason as to why. Can you give a realistic use case that would be prevented by this?
|
|
||
| Another important point to note is that `dataHash` is potentially more | ||
| efficient on large `Data`, since the hash can be computed without storing | ||
| the entire serialisation of the `Data` in memory. |
There was a problem hiding this comment.
This is something which should be detailed in the "Path to active" section as the most straight-forward blake2b_256 . serialiseData implementation (and thus easiest to develop and maintain) would not have that property. Only a hand-crafted serialize + hash routine might have these resource benefits.
There was a problem hiding this comment.
I fundamentally disagree with this. This is a core property of dataHash. According to CIP-35, this is where it ought to be. You can make bad implementations of anything.
|
|
||
| Implementation-wise, it should also be simpler than `serialiseData`, since | ||
| there are no considerations wrt. what the format of the serialisation should be, | ||
| because it's never exposed to users. |
There was a problem hiding this comment.
This is unfortunately not the case and tying the semantics of how the data is serialized and then hashed within this primitive to "whatever is available in off-chain dataHash" is not sufficient for non-Haskell use cases and potential source of regressions. As commented above, a specification of the actual binary representation for Data is required.
There was a problem hiding this comment.
...non-Haskell use cases? If you want to replicate this hashing algorithm in e.g. Rust, you just use whatever hashing algorithm Plutus already uses for txInfoData. How do you think https://github.com/input-output-hk/jormungandr would be implemented?
|
Do note #218 (comment) |
KtorZ
changed the title
dataHashdataHash
|
The Plutus team decided to adopt #218 as a new built-in, making this proposal now redundant. For the sake of keeping a track record, we may still want to merge this proposal as |
|
The primary reason for adopting #218 over this was the argument from increased composability. |
|
What should I change concretely? status to rejected? |
KtorZ
changed the title
dataHashdataHash
KtorZ
changed the title
dataHashdataHash
KtorZ
added
tentative CIP
State: Likely Deprecated
|
@L-as mind if we close this PR or are you willing to mark it as |
Replaces #218
Rendered