Conversation
igamigo
left a comment
There was a problem hiding this comment.
LGTM. I didn't look too much into this but the two endpoint variants require note details that quite closely resemble what the variants in NoteFile represent (https://github.com/0xMiden/protocol/blob/next/crates/miden-standards/src/note/file.rs#L75-L95) so I wonder if it's possible to reuse those messages.
| // Unverified lower bound for the inclusion block. An absent value differs from block zero. | ||
| optional blockchain.BlockNumber after_block_num = 2; |
There was a problem hiding this comment.
Should we make this non-optional? I don't believe there is currently any value in it being optional at all, but maybe I'm missing something
There was a problem hiding this comment.
We just kept the behavior of the note transport layer, where this has been optional. Are you saying that the client is always sending the after_block_num hint?
| // Optional unverified lower bound supplied through SendNote. | ||
| // An absent value differs from block zero. | ||
| optional blockchain.BlockNumber after_block_num = 3; | ||
| // Exact inclusion block verified through SendNoteWithProof. | ||
| // This field is absent for notes stored through SendNote. | ||
| optional blockchain.BlockNumber included_in_block = 4; |
There was a problem hiding this comment.
Can this be a oneof? Not sure if the plan is to keep SendNote or not
There was a problem hiding this comment.
There are two ways forward:
- We remove
SendNoteand keep only the verified submission path. In that case I wouldn't convert this to aoneof. - @bobbinth suggested that we can also keep
SendNotebut keep unverified notes only for a short time (a few minutes). If the note is not included on chain within that time we'd just remove them. Personally I think having both paths is a bit overlapping in functionality.
The second route basically wouldn't need changes in the client -- you could still submit notes without a proof and the note transport layer would take care of checking which of those get included on chain (and evict the rest).
However, if we change the client to wait for inclusion before submitting the note there's now point in keeping SendNote IMO.
4eed76f to
7733be0
Compare
31653e0 to
a67c3e0
Compare
a67c3e0 to
bf13fe5
Compare
bf13fe5 to
a84c58b
Compare
For notes that have been submitted with proofs we now store the exact inclusion block number.
a84c58b to
409961d
Compare
Summary
SendNoteWithProofendpoint to verify inclusion against a configured trusted node before storing notes. Cache note root commitments fetched from the trusted node with a bounded LRU and retry transient lookups within the request timeout budget.after_block_numhints from verifiedincluded_in_blockvalues in fetch responses and storage.Changelog