0xMiden/protocol

Move standards types from `miden-protocol` to `miden-standards`

Open

#2.214 geöffnet am 29. Dez. 2025

Auf GitHub ansehen
 (6 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Rust (139 Forks)github user discovery
good first issueruststandards

Repository-Metriken

Stars
 (123 Stars)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

As a follow-up to #2197, I think we should move some types from miden-protocol to miden-standards. The main motivation is to have types that are likely going to be extended in the future in the standards crate rather than in the protocol crate. Additionally, the protocol crate is fairly large after #1563 and this makes it a bit leaner.

This applies to:

  • miden_protocol::asset::TokenSymbol
    • used as part of fungible faucet metadata, which are defined as miden standards.
  • miden_protocol::address
    • The Address is not something that is inherently a part of the protocol, but more like a tool for working with it. The AddressInterface and RoutingParameters are meant to be extended through standardization and so it makes sense to have it in the standards crate.
    • Something to figure out here is how to make AddressId::decode delegate to AccountId::from_bech32_byte_iter without making types from the bech32 crate part of our public API. This can probably be done fairly simply by changing the iterator parameter to an impl Iterator<Item = u8>.
  • miden_protocol::account::component::AccountComponentMetadata Edit: This was now integrated into AccountComponent.
  • miden_protocol::account::auth::{AuthScheme, AuthSecretKey, PublicKey, Signature}.
    • These are less clear to me. They are used protocol-wide, and so one could argue that defining them in the protocol crate is fine. They are likely to be extended in the future with more standardized auth schemes, so it could make sense to move these to standards, or at least there should be no downside to doing so.
      • This requires moving AccountFile to standards as well, but that seems fine. If we do that, it probably also makes sense to move NoteFile.
      • One issue is that TransactionArgs::add_signature relies on Signature, and so moving these types would require a different solution here, like a trait or moving add_signature (as an extension trait) itself to standards. I think the latter makes the most sense.
      • Even if we move this to standards, it should be fine to keep miden_protocol::crypto re-exports.

I think TokenSymbol and Address make sense to be moved. For the other two I'm less convinced, but would lean towards moving them.

If we decide to move these, each of these high-level bullet points should be done as a separate PR.

Contributor Guide