Originally discussed in the context of PSWAP payback note attachments, a potential optimization exists for sending out note-related data to clients when doing SyncNotes, where a NoteSyncRecord could carry plain single-word attachments, instead of commitments to them.
The optimization would be based on the fact that clients may be able to derive all the necessary information related to the note (so as to avoid getting note details through GetNotesById, for example). In the case of the PSWAP note, a client would be able to derive whether a payback note relates to a swap that they started, and by how much the partial swap was completed. Because they also know all the details from the original order, they can know precisely what the payback note details look like. This way, they don't need to separately query GetNotesById to get them.
This should be doable (AFAIK) with no impact in used bandwidth or other resources. Also, I think this is doable right now in the node, though it may benefit from refactoring protocol structs a bit, not sure. It probably is not too high priority either but it may make sense to do it anyway as it is more valuable to send out actual data over commitments wherever possible.
Originally discussed in the context of
PSWAPpayback note attachments, a potential optimization exists for sending out note-related data to clients when doingSyncNotes, where aNoteSyncRecordcould carry plain single-word attachments, instead of commitments to them.The optimization would be based on the fact that clients may be able to derive all the necessary information related to the note (so as to avoid getting note details through
GetNotesById, for example). In the case of the PSWAP note, a client would be able to derive whether a payback note relates to a swap that they started, and by how much the partial swap was completed. Because they also know all the details from the original order, they can know precisely what the payback note details look like. This way, they don't need to separately queryGetNotesByIdto get them.This should be doable (AFAIK) with no impact in used bandwidth or other resources. Also, I think this is doable right now in the node, though it may benefit from refactoring protocol structs a bit, not sure. It probably is not too high priority either but it may make sense to do it anyway as it is more valuable to send out actual data over commitments wherever possible.