-
Notifications
You must be signed in to change notification settings - Fork 83
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
dev: improve rlp.cairo to support recursive list #457
Conversation
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.
First review, will have more questions in the coming days as I have more time to do a second review
Made a better recursive implementation for the rlp_decode(). |
2860336
to
7a34842
Compare
Interestingly, there was a bug in the compiler, it'll be fixed in the next release |
9cfb973
to
758eeb2
Compare
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.
lgtm
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.
Congratulations! Well fought
Implemented recursive struct in rlp.cairo to be able to handle recursive list. I also tried to be as close as the code given in the ethereum doc ; https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/ .
Here is a list of the biggest changes :
decode_type()
( formerfrom_bytes()
) now takes an array to be able to retrieve the long strings/lists size. It does now return the type which is either a string or a list, the offset at which it starts and its size.decode()
is now recursively called in case of recursive lists.Here is a screenshot of gas consommation before the modifications ;
And here is one after the modifications ;
It's worth noting that some tests show improvement.
For instance, the
test_decode_string
appears to consume more gas than before, but this test is essentially a loop that converts a single character into an array, explaining the increased gas consumption. But on the other hand, thetest_decode_long_list
test, which deals with a larger amount of bytes, consumes less gas than it did originally.I am certain that there is still potential for further improvement, and I would appreciate feedback on the direction these changes are taking. Whether you agree or disagree with some of the modifications.
Pull Request type
Please check the type of change your PR introduces:
What is the current behavior?
rlp.cairo.decode()
doesn't handle recusrive list.Resolves: #428
What is the new behavior?
Does this introduce a breaking change?