Create network target account helpers

[mmagician]

I think we need ~3 helpers in miden::standards::network_account_target, something like:

• const ATTACHMENT_SCHEME = NetworkAccountTarget::ATTACHMENT_SCHEME
• get_id(NoteAttachment) -> AccountId
  • This asserts attachment_scheme == NetworkAccountTarget::ATTACHMENT_SCHEME.
  • This assumes the attachment scheme was checked and simply returns the account ID. We may want to validate the account ID before returning?
  • A getter for note execution hint may not be necessary.
• new(AccountID, NoteExecutionMode) -> NoteAttachment
  • Looks like that's not necessary for this PR, but you're creating network notes in the bridge_out.masm using the note tag, which should be replaced with a call to this function.

Then you can just use network_account_target::get_id here. The constant is useful to add in case some other code wants to inspect the attachment scheme and branch on it instead of panicking (which is what get_id would do). I think this will be needed in other places so there is a benefit of moving this to miden::standards, and avoids low-level code here.

Originally posted by @PhilippGackstatter in #2334 (comment)

[mmagician]

@PhilippGackstatter on the second point:

get_id(NoteAttachment) -> AccountId

we'd additionally need to pass in the metadata word if we want to check the attachment scheme. I think the interface should then be:

#! Returns the ID encoded in the attachment.
#!
#! Inputs:  [NOTE_ATTACHMENT, NOTE_METADATA_HEADER]
#! Outputs: [target_id_prefix, target_id_suffix]
pub proc get_id

---

As far as the placement of this file, I was thinking miden::standards::attachment::network_account_target. Or do you think this would go directly under standards (would be the first stand-alone file there, but maybe that's ok)?

[PhilippGackstatter]

As far as the placement of this file, I was thinking miden::standards::attachment::network_account_target.

Yes, (miden::standards::attachments - plural) would be consistent with our current approach to naming in miden::standards, but I'm still of the opinion that this way of categorizing will quickly become messy (described in #2225 (comment)). I have to think a bit more about a concrete proposal for restructuring, so for now, this seems like the way to go.

[mmagician]

closed in #2338