-
Notifications
You must be signed in to change notification settings - Fork 106
add b2agg ntx tag check
#2189
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
Open
partylikeits1983
wants to merge
2
commits into
next
Choose a base branch
from
ajl-b2agg-ntx-tag-check
base: next
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
add b2agg ntx tag check
#2189
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know very little about the agglayer design, so this is just a question. At first glance, this looks a lot like a target account ID check in a P2ID note, except we're using the note tag instead of note inputs. Why can we not use note inputs instead?
The way I understand it is that we want a B2AGG note to be only consumed by a specific, canonical network faucet instead of any faucet that has a matching account interface. If that's true, then its account ID should be known and we should be able to use note inputs instead?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we could add it to the note inputs, but then we'd have to increase the size of the note inputs of the B2AGG note
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think with #2109 in mind, it will be easier to rely on note inputs instead of the format we'll end up using for network account targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that would be preferable indeed to include it in note inputs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds like a plan, will refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought a bit about your comment on this topic in the call. I think it could be fine to check the target account ID via the note attachment, in the future.
We'll only have
NoteAttachment::RawandNoteAttachment::Commitmentafter #2109 and I personally would like to avoid adding aNetworkAccountvariant. Primarily because network notes and txs have very little support at the protocol level and they already work fine. Instead of enshrining more network transaction things at the protocol level, it'd be amazing to make network notes a miden standard instead of a miden protocol feature, to keep the protocol lean. The few things we do have in the protocol can be done in other ways now that we have named storage slots (detecting network accounts) and once we have user-extensible note attachments (detecting network account targets). Specifically, the last part, relevant here, can be specified as a miden standard.So, checking via the note tag/attachment is possible but would make the agglayer more dependent on the network transaction "standard", i.e. the layout of how target account IDs are encoded in a note attachment. That's probably fine, because the agglayer already strongly assumes network transactions, afaict, but it's an additional thing to keep in mind.
On the other hand, having the target account ID in the note inputs sidesteps the network transaction specifics, as it becomes simply part of the "agglayer standard". This comes at the cost of being less efficient and encoding the account ID twice.
So, to summarize, I think checking via the tag/attachment is fine and probably a good idea to avoid that inefficiency. Also, the network transactions as a standard instead of a protocol feature is only an idea at this point that needs to be discussed more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the question is whether we'd want to make note attachments accessible programmatically. My initial thinking was that no - but now I'm wondering if maybe we should do this. So, then this boils down to:
If we decide to go with option 1, we can refactor this PR now. If we go with option 2, we should wait until #2109 is implemented.
I am leaning slightly toward option 2.