NoteTag requirements and simplification
#1449
Replies: 3 comments 14 replies
-
That's basically it.
I agree with this: for network notes, script root is a better use case identifier. We just need to know that a given public note is a network note - but for this a single bit should be sufficient. Beyond this, the tag may not be really necessary.
One challenge with using the tag for non-network notes is that we want to minimize node complexity. So, there are only 2 ways users can query notes:
We could add ability to query by script as well, but that means the node will need to index notes by script roots too, and the RPC API will need to support it. Moreover, script roots are available only for public notes. Though, there is argument to be made that retrieving private notes by use case tag is not super useful (unless we already know note details).
Maybe we should re-think the For private notes, having just 64 bits for the |
Beta Was this translation helpful? Give feedback.
-
|
I think we can split this in roughly two high-level categories:
The private use case is not clear to me yet. When receiving a private use case note such as a SWAP note, wouldn't the tag also be useful to retrieve note authentication paths with some privacy guarantees, similar to when the note is targeted at a private account ID?
Would the note tag look the same as the SWAP tag, i.e. contain the requested and offered asset? And what would the |
Beta Was this translation helpful? Give feedback.
-
Great question let me explain: 1. Computing serial numbers in the SWAPP note
Because both operands for computing serial numbers are deterministic, Alice can pre-compute the entire sequence 2. NoteRecipient can be cached up-frontNoteRecipient {
serial_num = p2id_serial_k // from table above
script_root = P2ID_SCRIPT_ROOT // constant
input_commitment = hash(AliceAccountId) // constant
}All three fields already live on Alice’s machine, so discovery is effectively O(1). Its easy for Alice to compute all future 3. What still has to ride along in the tagThe only thing Alice cannot derive is the filled amount. The faucet ID is implicit because she knows the SWAPP note and its requested asset; the tag just needs to carry the amount of that asset that ended up in the P2ID note (in this case the P2ID note carries exactly one asset). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Note tags might be a bit more complicated than they need to be and @bobbinth mentioned an alternative approach:
Taking a step back, one open questions for me is whether there is an exhaustive set of requirements that the note tag should fulfill. Is it basically this?
If that's the two main uses, then I think this simplification should work well. Note tags starting with
1are directed for accounts and those starting with0are use cases. The main questions for me are around the use case tags.Use Cases
I wonder if having a use case ID is necessary. A use case tag for a SWAP note could also be
[SWAP_SCRIPT_ROOT | offered_asset_faucet_id[..16] | requested_asset_faucet_id[..16]]. Basically, all use cases tags would be of size 32 + 4 bytes, but theNoteTagfor a use case note would only contain the latter 4 bytes. So the main change would be that for use cases, clients would request the script root + the note tag, while for account targets they would request just the note tag.Network Use Case
Currently we also have
NoteTag::NetworkUseCase, which identifies a use case note that should be consumed by network accounts. If network accounts expose the set of script roots they are willing to consume and with the above use-case changes, is that a sufficient replacement? Overall, the script root is a better use-case identifier than a note tag anyway, because a script root commits to the actual code while a tag could be (maliciously) crafted as well.If it's not sufficient, then network accounts would probably also have to expose a set of note tag use cases they are willing to consume, otherwise I'm not sure how a node would figure out which use case notes to put into a network transaction. A good example for this is a matcher account (deployed as a network account) for SWAP(P) notes as mentioned in #1333. Though such a matcher account is probably interested in all SWAP(P) notes, and not just a specific
POL/ETHpair.One additional thing to discuss in this context is the trade-off between the note tag and the
auxvalue in the note metadata. For instance, we could swap the representations of the tag and the aux value, i.e. make the note tag from aFeltand reduce the aux to au32.That would allow having the
NoteTag::NetworkAccountcontain a full account ID prefix which would, at least currently, uniquely identify an account. This would eliminate any ambiguity in the node when figuring out which account is targeted by a certain network note. Something that is not clear to me is what theauxvalue should be used for and what size is sufficient.I'm a bit hesitant about this though because I don't necessarily want us to further commit to "account ID prefixes are unique" as we could lift this restriction if we were to refactor assets. We could potentially come back to this after we've discussed programmable assets.
Beta Was this translation helpful? Give feedback.
All reactions