https://github.com/snario/zknifty

🎴Zero-knowledge non-fungible tokens on Ethereum using zk-SNARKs
https://github.com/snario/zknifty

blockchain eddcsa erc721 ethereum zksnarks

Last synced: 2 months ago
JSON representation

🎴Zero-knowledge non-fungible tokens on Ethereum using zk-SNARKs

• Host: GitHub
• URL: https://github.com/snario/zknifty
• Owner: snario
• License: mit
• Created: 2018-09-08T14:27:23.000Z (almost 7 years ago)
• Default Branch: master
• Last Pushed: 2018-09-10T11:22:42.000Z (almost 7 years ago)
• Last Synced: 2025-03-23T20:11:17.454Z (3 months ago)
• Topics: blockchain, eddcsa, erc721, ethereum, zksnarks
• Language: Python
• Homepage:
• Size: 237 KB
• Stars: 93
• Watchers: 7
• Forks: 22
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        


     

    
zknifty: Zero-knowledge transactions of non-fungible tokens on Ethereum 



zknifty is an experiment in using an implementation of zero-knowledge merkle tree proofs to facilitate bulk transactions of non-fungible tokens on Ethereum. It was built as a hack at [ETHBerlin](https://ethberlin.com). This work was **strongly** inspired and influenced by https://github.com/barryWhiteHat/roll_up.

# How it works

Merkle trees can lead to significant data compression for smart contracts, where an entire contract state can be compressed in a single `bytes32` hash on-chain. In this NFT repository, each leaf of the merkle tree represents the ID of a Non-Fungible Token and each leaf also stores the current owner of the corresponding token. This design could allow us to transfer an arbitrary number of tokens with a single transaction updating the root of the merkle tree. However, since the data composing the merkle-tree is stored off-chain, it is difficult for contracts to validate changes to the merkle tree. Here, we utilize the properties of zk-SNARKs to guarantee that the merkle tree was updated according to verify specific rules. These rules are currently as follow :

* The actual owner of the token to be transferred signed a message

* This message is composed of the token ID and the receiver address

* The signature is valid (eddsa signature scheme)

* The token transfer is reflected in the new merkle tree

The token contract will accept a new merkle root **only if** all the conditions above are met. This is possible by providing a zk-SNARK proof to the token contract with the new merkle root. Additional conditions are needed to make the contract secure, hence **this contract is not to be used in production**. 

---

**Presentation Slides** : 

https://docs.google.com/presentation/d/1aHfaHy_FPxF0fHw-9EuCTUImhFxwRv63mDTZMPVgdg0/edit?usp=sharing