Skip to content

Document Ethereum ↔ Miden address conversion specification#2513

Merged
mmagician merged 4 commits intommagician-agglayer-specfrom
claude/add-address-conversion-spec-RSgeF
Mar 2, 2026
Merged

Document Ethereum ↔ Miden address conversion specification#2513
mmagician merged 4 commits intommagician-agglayer-specfrom
claude/add-address-conversion-spec-RSgeF

Conversation

@mmagician
Copy link
Copy Markdown
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

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
Copy Markdown
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?

@mmagician mmagician added no changelog This PR does not require an entry in the `CHANGELOG.md` file agglayer PRs or issues related to AggLayer bridging integration pr-from-maintainers PRs that come from internal contributors or integration partners. They should be given priority labels Mar 2, 2026
claude and others added 3 commits March 2, 2026 12:19
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
Update crates/miden-agglayer/SPEC.md

Update crates/miden-agglayer/SPEC.md

Update crates/miden-agglayer/SPEC.md
@mmagician mmagician force-pushed the claude/add-address-conversion-spec-RSgeF branch from 8fd1fc1 to 76f17e8 Compare March 2, 2026 12:21
@mmagician mmagician marked this pull request as ready for review March 2, 2026 12:39
@mmagician mmagician merged commit 9f35994 into mmagician-agglayer-spec Mar 2, 2026
15 checks passed
@mmagician mmagician deleted the claude/add-address-conversion-spec-RSgeF branch March 2, 2026 12:40
mmagician added a commit that referenced this pull request Mar 4, 2026
* chore: new SPEC file

* feat: entities and permissions

* feat: contracts and public interfaces

* feat: integrate contract storage into sec 2.

* feat: notes, incl properties, storage, consumption

* feat: match Rust fields for note spec

* docs: update SPEC.md for resolved issues and current bridge design

* docs: address review comments on SPEC.md

- Update baseline to "to-be-tagged v0.14-alpha"
- Add explanation for why native claim amount is verified (avoids
  expensive U256 division inside the VM)
- Simplify addr output notation to addr(5)

https://claude.ai/code/session_01UDgsAS2j2CFrTLsDoLiSUN

* chore: update docs to match latest agglayer branch

* docs(AggLayer): Ethereum <> Miden address conversion specification (#2513)

* docs: add Section 5 — Ethereum ↔ Miden address conversion spec

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

* Apply suggestions from code review

Update crates/miden-agglayer/SPEC.md

Update crates/miden-agglayer/SPEC.md

Update crates/miden-agglayer/SPEC.md

* fix: EthAddressFormat::from_account_id usage

* docs: clean up address conversion

---------

Co-authored-by: Claude <noreply@anthropic.com>

* chore: add sec 4. placeholder

* chore: add a note about encoding of u32s in note storage

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agglayer PRs or issues related to AggLayer bridging integration no changelog This PR does not require an entry in the `CHANGELOG.md` file pr-from-maintainers PRs that come from internal contributors or integration partners. They should be given priority

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants