-
-
Notifications
You must be signed in to change notification settings - Fork 76
bugfix: fixed incorrect bytestring encoding PlutusData #269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
9492b5c
c92ecfb
6dbdd4f
b663a3b
364ba67
5a90438
c71dd82
945e52a
81abc6a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -149,7 +149,7 @@ def test_script_data_hash(): | |
redeemers = [Redeemer(unit, ExecutionUnits(1000000, 1000000))] | ||
redeemers[0].tag = RedeemerTag.SPEND | ||
assert ScriptDataHash.from_primitive( | ||
"032d812ee0731af78fe4ec67e4d30d16313c09e6fb675af28f825797e8b5621d" | ||
"b11ed6f6046df925b6409b850ac54a829cd1e7603145c9aaf765885d8ec64da7" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure if this should change. If we use write the same test in Haskell, it would generate the same hash. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think as you noticed in the other comment, this changes because all bytes are being encoded the same way per nielstrons suggestion. Your comment makes sense. If we only change encoding in metadata/plutusdata, then the hash would not change. |
||
) == script_data_hash(redeemers=redeemers, datums=[unit]) | ||
|
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, it seems incorrect to replace every bytes with ByteString. Instead, we just offer ByteString for users to use in PlutusData or Metadata.
For some internal implementation that generates bytes as intermediate values, e.g. script_data_hash, we don't want to change its type arbitrarily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be implementable by a simple parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was one of my original points and how I originally had it implemented.
Can someone please make a definitive final decision so I can fix and be done? I've implemented and reimplemented this multiple times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nielstron Could you elaborate how adding a parameter will work?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not work as straightforward as I imagined it. @theeldermillenial was right, maybe we should just roll with the initial design. I appreciate the excourse though because now we know precisely which bytes to encode this way 😅 sorry for the divergence.
maybe we can document this (and ideally find some supporting documentation on the discrepancy in the implementation)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My preferred approach is to offer users
ByteString
class to use, which the encoder can automatically break it down to byte array. If a bytes object is found longer than 64 instead, pycardano should raise an exception and recommend users to useByteString
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cffls But should this error only be thrown for
PolusData
and Metadata? Or should we apply it globally?My two cents is "only implement exactly what is defined". The bytes length restriction appears to be limited to "metadata", so maybe we only apply it to metadata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have this check for metadata: https://github.com/Python-Cardano/pycardano/blob/main/pycardano/metadata.py#L40-L49
I thought this should be also enforced in PlutusData, which was the reason why this PR was raised. If not, I am fine with only providing ByteString as an option for user in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My apologies. I misspoke. When I said Metadata, I also meant PlutusData.
Also, I now see exactly what you're saying, and I think you're solution makes the most sense. You are saying we should inject a check for long byte strings in PlutusData and throw an error similar to what is seen in Metadata. Part of that error message should indicate the user can use the new ByteString class to allow longer bytes.
I think this is the most transparent approach, and it keeps in line with what I see to be pycardano's philosophy of being very unbiased.
If this is what you mean, I'll make the changes and we can be done. I will revert any hashes I altered, since this should really only affect the test I created. If there's any other unit tests you would like to see, I'm happy to add them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is exactly what I meant. Please go ahead with this approach. Thank you for confirming.☺️