fix(l1,l2): make RLP integer impl_encode single-pass and zero-allocation #5409
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reworked impl_encode in crates/common/rlp/encode.rs to compute the first non-zero byte in a single pass and to encode using direct slices of the original big-endian array. This eliminates the previous double scan and avoids allocating/copying into ArrayVec, which was unnecessary for encoding the integer payload. As a direct consequence, this change also fixes a correctness bug where u128 encoding could panic at runtime due to relying on ArrayVec<[u8; 8]> and attempting to extend it with 16 bytes. The new logic preserves RLP semantics for zero (0x80), single-byte values in the 0x01..=0x7f range (encoded as-is), and multi-byte integers (prefixed with 0x80 + length followed by the trimmed big-endian bytes), aligning with how other parts of the module handle length-prefixed payloads without redundant work.