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(svm): Refactor deposit ID to use big-endian encoding in Bytes32 format #810

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

md0x
Copy link
Contributor

@md0x md0x commented Dec 19, 2024

Changes proposed in this PR:

  • Updated deposit ID storage format to use big-endian encoding
  • Refactored byte manipulation logic to ensure consistent big-endian encoding and decoding for 32byte arrays

Motivation:

Previously, "safe" (deposit_v3) deposit IDs were stored in little-endian (LE) format, causing friction for relayers and off-chain tools due to format conversions. Challenges included:

  1. Relayers had to convert BE (EVM standard) to LE, adding complexity.
  2. Special handling was required to extract and parse IDs stored in LE format see this
  3. Diverged from EVM conventions, complicating cross-chain operations.

Solution:

This PR stores "safe" (deposit_v3) deposit IDs in BE format, storing number_of_deposits in the right-most bits. This aligns with EVM, simplifies cross-chain operations and reduces off-chain parsing complexity

Note: The “unsafe” deposit (unsafe_deposit_v3) does not require any changes and is unaffected by these challenges, as it uses a generated hash without endianness considerations.

md0x added 4 commits December 19, 2024 13:25
Signed-off-by: Pablo Maldonado <[email protected]>
Signed-off-by: Pablo Maldonado <[email protected]>
Signed-off-by: Pablo Maldonado <[email protected]>
@md0x md0x changed the title Pablo/deposit id encoding feat(svm): Refactor deposit ID to use big-endian encoding in Bytes32 format Dec 19, 2024
@md0x md0x marked this pull request as ready for review December 19, 2024 14:37
Copy link
Contributor

@Reinis-FRP Reinis-FRP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, this should be easier for offchain to work with

@@ -117,7 +117,7 @@ pub fn _deposit_v3(
// If the passed in deposit_id is all zeros, then we use the state's number of deposits as deposit_id.
if deposit_id == ZERO_DEPOSIT_ID {
state.number_of_deposits += 1;
applied_deposit_id[..4].copy_from_slice(&state.number_of_deposits.to_le_bytes());
applied_deposit_id[28..].copy_from_slice(&state.number_of_deposits.to_be_bytes());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is great! I love how simple it is to get these structures to match what is expected here.

@@ -1,33 +1,16 @@
import { BN } from "@coral-xyz/anchor";
import { PublicKey } from "@solana/web3.js";
import { ethers } from "ethers";
import { BigNumber, ethers } from "ethers";

/**
* Converts an integer to a 32-byte Uint8Array.
*/
export function intToU8Array32(num: number | BN): number[] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might make sense at some point to have unit tests for these kinds of utils.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants