-
Notifications
You must be signed in to change notification settings - Fork 42
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
[feat] Optimize the way we serialize transactions #298
Comments
Hi @maciejka |
HMMMM |
@maciejka let work and optimize this part of the code, here is how i will approach,
|
Hey @maciejka Can I take this up, as I have worked with encode trait before |
Interested too. Exercise I've already done and am familiar with Encode |
hey @maciejka In the code, dest.append_word_rev(val, 1 or 2 or 3); we're appending val as either a 1-byte, 2-byte, or 3-byte value. Given that we’re trying to push these length values into an array, which uses 4 bytes (32 bits) per element, I’m wondering can we do we pad the remaining bytes with zeros when pushing into the array? or is there have anyother way . |
You can have a look at how it is implemented ByteArray: https://github.com/starkware-libs/cairo/blob/d390b0904fd7cc7d5a0b39b61a504a25483740de/corelib/src/byte_array.cairo#L36 There is a pending_word for data that does not take full word (in ByteArray case it is felt252, in our case it is u32). For conversion see: https://github.com/starkware-libs/cairo/blob/d390b0904fd7cc7d5a0b39b61a504a25483740de/corelib/src/byte_array.cairo#L227 |
Currently we use Encode trait to serialize data before hashing. There is a performance problem in this approach as ByteArray, which is a type of the buffer we serialize to, is not the type sha256 works with. So ByteArray needs to be converted to
Array<u32>
before hashing. It would be more optimal to useArray<u32>
as a buffer type in the codec module.The text was updated successfully, but these errors were encountered: