search

0xPolygonMiden / miden-client

Client library that facilitates interaction with the Miden rollup
MIT License
25 stars 22 forks source link

Note inclusion issues: InputNoteNotInBlock #319

Closed daedlock closed 2 months ago

daedlock commented 2 months ago

Environment:

miden-client 0.2.1 miden-node main (c4747bb81a8f6037dd634c165958b67ecab9564e)

Issue

I am getting this error while trying to consume a note that should be included in the last block.

called `Result::unwrap()` on an `Err` value: TransactionExecutorError(FetchTransactionInputsFailed(InvalidTransactionInput(InputNoteNotInBlock(NoteId(RpoDigest([1194276690315863851, 15620031744857253686, 13893341993908731926, 3425349220338027761])), 20))))

The error suggests that the InputNote to consume is not included in a block. However, after checking the miden-node db, it seems that the note is included in a block. Moreover, the note exists in the miden-client db with status Committed

Node store:

image

Client store:

image
igamigo commented 2 months ago

From what we've seen, it could be that perhaps the note that was attempted to be consumed could have slightly different details than the one that was actually created. Could this be the case? Is there any way you could provide a repro scenario for this problem?

daedlock commented 2 months ago

From what we've seen, it could be that perhaps the note that was attempted to be consumed could have slightly different details than the one that was actually created. Could this be the case? Is there any way you could provide a repro scenario for this problem?

Is it possible for 2 notes to be different but still have the same NoteId?

bobbinth commented 2 months ago

Is it possible for 2 notes to be different but still have the same NoteId?

Any two note objects which have the same set of assets, same script root, same inputs, and same serial number would have the same NoteId. If any of these fields is different between the two notes, their IDs will be different too.

Not sure if it is relevant here, but a note with the same ID be recorded many times in the chain, but can be consumed only once. So, for example, if for w/e reason we submit two transactions which output identical notes (i.e., notes with the same NoteId), both transactions will go through, but only one of these notes would be "spendable".

daedlock commented 2 months ago

Any two note objects which have the same set of assets, same script root, same inputs, and same serial number would have the same NoteId. If any of these fields is different between the two notes, their IDs will be different too.

That confirms my understanding. So, I can safely assume that the issue is not related to discrepancies between the actual and expected notes given that they have the same NoteId

Not sure if it is relevant here, but a note with the same ID be recorded many times in the chain, but can be consumed only once. So, for example, if for w/e reason we submit two transactions which output identical notes (i.e., notes with the same NoteId), both transactions will go through, but only one of these notes would be "spendable".

That makes sense, but in that case, shouldn't the error be something along the lines of NoteAlreadyConsumed/ NoteNullified? I don't think that's the issue but I will take a deep look to see if there is any chance this could be the case

igamigo commented 2 months ago

That confirms my understanding. So, I can safely assume that the issue is not related to discrepancies between the actual and expected notes given that they have the same NoteId

Sorry I wasn't too clear before. I don't think this is necessarily true. For example, if the aux field on the note's metadata were to differ, you could get this error. If I remember correctly, this was the case you were hitting some weeks ago. The reason why the Note ID would still be the same with a different field is that it is a commitment to the fields that @bobbinth mentioned, but in order to authenticate the note in the block, the authentication_hash() is used. This hash is a commitment to the NoteId and to the note's metadata. So in your case the ID could be the same but authentication_hash() could be yielding a different hash compared to the chain's actual note. This was the scenario I had in mind originally (similar to what we have seen some other times before).

daedlock commented 2 months ago

That confirms my understanding. So, I can safely assume that the issue is not related to discrepancies between the actual and expected notes given that they have the same NoteId

Sorry I wasn't too clear before. I don't think this is necessarily true. For example, if the aux field on the note's metadata were to differ, you could get this error. If I remember correctly, this was the case you were hitting some weeks ago. The reason why the Note ID would still be the same with a different field is that it is a commitment to the fields that @bobbinth mentioned, but in order to authenticate the note in the block, the authentication_hash() is used. This hash is a commitment to the NoteId and to the note's metadata. So in your case the ID could be the same but authentication_hash() could be yielding a different hash compared to the chain's actual note. This was the scenario I had in mind originally (similar to what we have seen some other times before).

You are indeed right! Thanks alot for clarifying that as it made me start looking in the right place. The issue turned out to be a subtle difference in NoteMetadata.

Thanks again! closing this issue as it's now resolved