Skip to content

Document Ethereum ↔ Miden address conversion specification#2513

Draft
mmagician wants to merge 1 commit intommagician-agglayer-specfrom
claude/add-address-conversion-spec-RSgeF
Draft

Document Ethereum ↔ Miden address conversion specification#2513
mmagician wants to merge 1 commit intommagician-agglayer-specfrom
claude/add-address-conversion-spec-RSgeF

Conversation

@mmagician
Copy link
Collaborator

Summary

This PR adds comprehensive documentation for the Ethereum ↔ Miden address conversion mechanism used by the AggLayer bridge. The specification covers the encoding format, conversion algorithms in both Rust and MASM, and usage patterns across the codebase.

Key Changes

  • Section 5: Ethereum ↔ Miden Address Conversion — New specification section documenting:

    • Background on Miden's AccountId structure (two field elements with specific bit layouts)
    • Embedded format showing how 16-byte AccountId values fit into 20-byte Ethereum addresses with 4-byte zero padding
    • MASM limb representation (address[5]) with big-endian limb order and little-endian byte order within limbs
    • Conversion procedures for both directions in Rust and MASM
    • Detailed endianness summary clarifying the two-level byte ordering convention
    • Usage matrix showing where conversions are applied (CLAIM notes, B2AGG notes, bridge-out leaves, etc.)
    • Roundtrip guarantee proof and limitations of the encoding
  • Example conversions — Three concrete Bech32 to Ethereum address mappings demonstrating the format

  • Error handling — Documented error conditions for invalid conversions (NonZeroBytePrefix, FeltOutOfField, InvalidAccountId)

  • Helper procedures — Specification of MASM helpers like build_felt and swap_u32_bytes for byte-order conversion

Notable Details

  • The encoding is a bijection over valid AccountId values, enabling reliable roundtrip conversion
  • The specification bridges implementation details across Rust (offchain) and MASM (in-VM) code paths
  • Clarifies the distinction between limb order (big-endian) and byte order within limbs (little-endian), which aligns with Solidity ABI conventions
  • Explicitly notes that not all Ethereum addresses are valid Miden accounts — the reverse conversion is partial

https://claude.ai/code/session_01YabAhXZeStAkKkYwBcXXFh

Comprehensive specification of the address conversion encoding between
Ethereum 20-byte addresses and Miden AccountId (two field elements),
covering the embedded format, MASM limb representation, Rust and MASM
conversion procedures, endianness details, and roundtrip guarantees.

Addresses #2229

https://claude.ai/code/session_01YabAhXZeStAkKkYwBcXXFh
Comment on lines +645 to +646
c. Pack into a felt: `suffix = bswap(limb3) × 2^32 + bswap(limb4)`.
d. Verify no mod-p reduction: split the felt back via `u32split` and assert equality
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

is this reduction back needed? could we not assert something on bswap(limb3) instead?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants