Lyd/ignore sent commitments#497
Merged
Merged
Conversation
lydiagarms
force-pushed
the
lyd/ignoreSentCommitments
branch
3 times, most recently
from
July 16, 2026 13:48
7fc8394 to
72e1a9b
Compare
lydiagarms
marked this pull request as ready for review
July 17, 2026 08:38
Wei-257
reviewed
Jul 17, 2026
| } | ||
|
|
||
| function getLocalPublicKeys() { | ||
| if (!fs.existsSync(keyDb)) return []; |
There was a problem hiding this comment.
do we allow empty set? is key initialization guranteed?
If empty set, then line 274, 319 and 335 will return null even when commitments exists.
do you want to return an empty filter object here or fail explicitly with a clear error that keys must be initialised?
Collaborator
Author
There was a problem hiding this comment.
Good point, fixed in fixup commit: 6560fe5
AdarshRon
reviewed
Jul 20, 2026
Wei-257
approved these changes
Jul 21, 2026
lydiagarms
force-pushed
the
lyd/ignoreSentCommitments
branch
from
July 21, 2026 08:48
6560fe5 to
ff925d8
Compare
|
🎉 This PR is included in version 1.10.13 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
In the commitment DB in Starlight, we store commitments that are created on behalf of another user. However, if it is a whole variable this could cause a problem if the ownership of that variable is later transferred back to us. Consider the contract NFT_Escrow.zol, lets say we transfer a token to another user, and they then transfer it back to us. We will save the commitment during the initial transfer that we are sending to another user. We then receive another commitment with the same state id. However, because the first commitment is owned by the other user, we will never learn that it has been nullified as we do not own the variable and so don't know the nullifier. Therefore, if we try to use the token sent to us, we will use the first commitment instead of the second which causes an error.
Changes
When we call getCommitmentsDb, getBalance and getBalanceByState we filter commitments so that the public key is either the default one or the shared public key.
Previously, in contracts like BucketsOfBalls.zol where the ownership is a public address, we obtain the public key for new commitments by checking the on-chain mapping, even if this has not been set. If this is the case the public key used will be 0, which will mean that it will be filter out as per the previous change. As is already the case for secret addresses, we should default to the optional public key chosen by the user in the API call, then use the on-chain mapping if it exists, and otherwise use the default public key.
Checklist
How to test