Lock states #110
Merged
Lock states #110
Conversation
This file contains 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
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Chengxuan
reviewed
Dec 16, 2024
There was a problem hiding this comment.
@jimthematrix I couldn't figure out how we protect locked UTXOs not to be withdrawn.
Can we add a test for that?
| for (uint256 i = 0; i < utxos.length; ++i) { | ||
| utxosArray[i] = utxos[i]; | ||
| } | ||
| for (uint256 i = utxos.length; i < 10; ++i) { |
There was a problem hiding this comment.
hard coded batch size of 10 in the condition, could this be replaced with MAX_BATCH?
solidity/contracts/zeto_anon.sol
Outdated
Comment on lines
61
to
62
| address _lockVerifier, | ||
| address _batchLockVerifier |
There was a problem hiding this comment.
Should these not using the interface types rather than address?
| @@ -382,6 +383,52 @@ describe("Zeto based fungible token with anonymity without encryption or nullifi | |||
| }); | |||
| }); | |||
|
|
|||
| describe("lockStates() tests", function () { | |||
There was a problem hiding this comment.
Should add a test for withdraw()
| // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| // See the License for the specific language governing permissions and | ||
| // limitations under the License. | ||
| pragma circom 2.1.9; |
There was a problem hiding this comment.
should consider 2.2.1 for new circuits
| // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| // See the License for the specific language governing permissions and | ||
| // limitations under the License. | ||
| pragma circom 2.1.9; |
There was a problem hiding this comment.
same comment here for the version
|
thanks @Chengxuan for catching the missing checks in the withdraw() function. will add to the next commit along with addressing your other comments |
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Signed-off-by: Jim Zhang <[email protected]>
Chengxuan
approved these changes
Dec 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Replace
lockProof()withlockStates(), because lockProof() is keyed off of the proof bytes which doesn't guarantee uniqueness of the individual states to be spent. As such it can't prevent the owner from spending the state(s) that are supposed to be used in a multi-step flow such as DvP.For example, consider the following scenario:
assetUTXO-1, and Bob sends Alice payment two tokenspaymentUTXO-1andpaymentUTXO-2p1, for transferring assetUTXO-1 to assetUTXO-2 with Bob as the ownerp1and sets the DvP contract as the delegate (who is allowed to submit the proof to complete the transfer)p2, for spending bothpaymentUTXO-1andpaymentUTXO-2in order to pay Alicep2and sets the DvP contract as the delegatepaymentUTXO-1to pay Charlie for another trade, that transaction will be successful because it uses a different proofpaymentUTXO-1, in the input is already spentUsing lockStates() on the other hand, can guarantee that the individual input states are locked and delegated to an orchestration contract, which is the only account that can unlock or spend the states.