You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This library assumes that account value is left padded while proof is right padded.
I wanted to ask - if there is a specific reason for it.
As far as I see - noir code doesn't make use of the left-paddingness of account and just immediately converts it back to a right-padded value. Also rust code needs to implement left_pad function while right padding just concats with the zero vec.
Unless I miss something here - switching to right-padded values will make rust code simpler and circuit smaller
The text was updated successfully, but these errors were encountered:
Thanks for bringing this up! The initial motivation was to mirror the storage proof structure where values are naturally represented as left-padded big-endian byte arrays, but even in that case the value embedded in a proof is itself RLP-encoded so that a case could be made for right-padded. In any case, I agree that it would make sense to move to right-padded values for state proofs, which would result in a constraint reduction of around 9k.
This library assumes that account value is left padded while proof is right padded.
I wanted to ask - if there is a specific reason for it.
As far as I see - noir code doesn't make use of the left-paddingness of account and just immediately converts it back to a right-padded value. Also rust code needs to implement left_pad function while right padding just concats with the zero vec.
Unless I miss something here - switching to right-padded values will make rust code simpler and circuit smaller
The text was updated successfully, but these errors were encountered: