Add script_data_hash computation. #512
Conversation
|
|
||
| let mut buf = Vec::new(); | ||
| if redeemers.len() == 0 && datums.is_some() { | ||
| buf.push(0xA0); |
There was a problem hiding this comment.
This is the value that changed from 0x80 -> 0xA0 for Conway Era, correct?
There was a problem hiding this comment.
yes, and is just a side effect of encoding an empty map of redeemers.
To correctly handle this, the different era implementations of redeemers should have era-specific serialization code; because Chang+1 will mean the redeemers now must be encoded as a map.
There was a problem hiding this comment.
instead of handling cbor bytes directly, it would be easier / safer to have a struct ScriptData that implements cbor encoding and contains the underlying data parts (empty maps and such nuances would be handled by the data type).
This struct could live inside primitives crate and get versioned by era (babbage:ScriptDataHash, conway:ScriptData, etc).
| // TODO: script_data_hash computation | ||
| pub fn script_data_hash(mut self, hash: Hash<32>) -> Self { | ||
| pub fn script_data_hash(mut self, redeemers: Vec<Redeemer>,datums: Option<Vec<PlutusData>>, version: PlutusVersion) -> Self{ | ||
| let plutus_v1_costmodel: Vec<u8> = vec![161, 65, 0, 89, 1, 166, 159, 26, 0, 1, 137, 180, 25, 1, 164, 1, 1, 25, 3, 232, 24, 173, 0, 1, 25, 3, 232, 25, 234, 53, 4, 1, 25, 43, 175, 24, 32, 26, 0, 3, 18, 89, 25, 32, 164, 4, 25, 62, 128, 24, 100, 25, 62, 128, 24, 100, 25, 62, 128, 24, 100, 25, 62, 128, 24, 100, 25, 62, 128, 24, 100, 25, 62, 128, 24, 100, 24, 100, 24, 100, 25, 62, 128, 24, 100, 26, 0, 1, 112, 167, 24, 32, 26, 0, 2, 7, 130, 24, 32, 25, 240, 22, 4, 26, 0, 1, 25, 74, 24, 178, 0, 1, 25, 86, 135, 24, 32, 26, 0, 1, 100, 53, 25, 3, 1, 4, 2, 26, 0, 1, 79, 88, 26, 0, 3, 124, 113, 24, 122, 0, 1, 1, 25, 3, 232, 25, 167, 169, 4, 2, 25, 95, 228, 25, 115, 58, 24, 38, 1, 26, 0, 13, 180, 100, 25, 106, 143, 1, 25, 202, 63, 25, 2, 46, 1, 25, 153, 16, 25, 3, 232, 25, 236, 178, 1, 26, 0, 2, 42, 71, 24, 32, 26, 0, 1, 68, 206, 24, 32, 25, 59, 195, 24, 32, 26, 0, 1, 41, 17, 1, 25, 51, 113, 4, 25, 86, 84, 10, 25, 113, 71, 24, 74, 1, 25, 113, 71, 24, 74, 1, 25, 169, 21, 25, 2, 40, 1, 25, 174, 205, 25, 2, 29, 1, 25, 132, 60, 24, 32, 26, 0, 1, 10, 150, 24, 32, 26, 0, 1, 26, 170, 24, 32, 25, 28, 75, 24, 32, 25, 28, 223, 24, 32, 25, 45, 26, 24, 32, 26, 0, 1, 79, 88, 26, 0, 3, 124, 113, 24, 122, 0, 1, 1, 26, 0, 1, 97, 66, 25, 2, 7, 0, 1, 26, 0, 1, 34, 193, 24, 32, 26, 0, 1, 79, 88, 26, 0, 3, 124, 113, 24, 122, 0, 1, 1, 26, 0, 1, 79, 88, 26, 0, 3, 124, 113, 24, 122, 0, 1, 1, 26, 0, 4, 33, 60, 25, 88, 60, 4, 26, 0, 22, 60, 173, 25, 252, 54, 4, 25, 79, 243, 1, 4, 0, 26, 0, 2, 42, 168, 24, 32, 26, 0, 1, 137, 180, 25, 1, 164, 1, 1, 26, 0, 1, 62, 255, 24, 32, 25, 232, 106, 24, 32, 25, 78, 174, 24, 32, 25, 96, 12, 24, 32, 25, 81, 8, 24, 32, 25, 101, 77, 24, 32, 25, 96, 47, 24, 32, 26, 3, 46, 147, 175, 25, 55, 253, 10, 255]; |
There was a problem hiding this comment.
Why are these values hardcoded? They should come from the costmodels in protocol params.
There was a problem hiding this comment.
i cant find anything inside pallas on how to get cost models, this should be constant right?, also cost models ends up in language view, i've had @hrpr help me on how to get the correct language view so i figured to hard code it to avoid the hassle.
There was a problem hiding this comment.
cost models are an updatable protocol parameter that can change at any time. They should be retrievable from a live node in n2c mode doing a protocol parameters query.
There was a problem hiding this comment.
In particular, for this patch, they should be passed in to the script data hash function. I think Pallas already has types for the cost models over where the protocol parameters are defined?
No description provided.