Skip to content
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

Closed
maciejka opened this issue Nov 5, 2024 · 7 comments · Fixed by #306
Closed

[feat] Optimize the way we serialize transactions #298

maciejka opened this issue Nov 5, 2024 · 7 comments · Fixed by #306
Assignees
Labels
advanced help wanted Extra attention is needed

Comments

@maciejka
Copy link
Collaborator

maciejka commented Nov 5, 2024

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 use Array<u32> as a buffer type in the codec module.

@maciejka maciejka added help wanted Extra attention is needed advanced labels Nov 5, 2024
@ShantelPeters
Copy link

ShantelPeters commented Nov 5, 2024

Hi @maciejka
Please can I work on this?

@mubarak23
Copy link
Contributor

Hi @maciejka Please can I work on this?

HMMMM

@mubarak23
Copy link
Contributor

mubarak23 commented Nov 5, 2024

@maciejka let work and optimize this part of the code,

here is how i will approach,

  • Change Buffer Type: Update the codec module to use Array as the default buffer type for the Encode trait instead of ByteArray.
    -Update Encoding Logic: Adjust the encoding logic to serialize data directly into Array. This may involve modifying the Encode trait implementation to work natively with Array.

  • Test and Benchmark: After implementing the change, thoroughly test the encoding and hashing process to ensure data integrity and then benchmark it to verify the performance improvement.

@PavitraAgarwal21
Copy link
Contributor

Hey @maciejka Can I take this up, as I have worked with encode trait before

@Jeanmichel7
Copy link
Collaborator

Jeanmichel7 commented Nov 5, 2024

Interested too. Exercise I've already done and am familiar with Encode

@PavitraAgarwal21
Copy link
Contributor

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 .
Also do you have any guidance on how to convert a u32 number into its little-endian form and append in the array ?

@maciejka
Copy link
Collaborator Author

maciejka commented Nov 8, 2024

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 . Also do you have any guidance on how to convert a u32 number into its little-endian form and append in the array ?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
advanced help wanted Extra attention is needed
Projects
None yet
5 participants