TEPs
TEPs copied to clipboard
ton-blockchain
Compressed NFT Standard
Hey @krigga! I like the idea, but I think we should make a standard NFT compressed contract with Merkle proofs instead of Merkle trees. First of all, we should use TON possibilities and TON has a convenient proof verifying technology. Secondly, it should be much cheaper.
I started such development in my fork (currently there is no Merkle Updates implementation for updates, its just an example of how the proof can be verified). So if the community like the idea I can continue development.
I think wallet developers should support exotic cells sending in wallets, because that's a good technology that can find application in many developments. So maybe its better to wait for wallets to support this feature?
For the first time we can use proxy contracts for NFT claiming: User deploys a simple proxy contract and then sends an external message with proof to it which proxy sends to the collection contract. The cost of deployment is offset by the cheapness of proof verification with tvm built-in Merkle Proof validation.
Hey, @yungwine Absolutely agree on your take on exotic cells. We actually have implementation of reference contracts using exotic cells, but as you mentioned no wallet currently supports them. We made your best to make this standard implementation-agnostic, this means that standard does not cover how exactly poofs are implemented. So there is no reason to change the standard itself, it could be adopted now. When the wallets will support exotic cells we will just change the reference implementation of contracts without changing the standard itself
I don't really understand why it is necessary to put all this in a separate standard. As an implementation of NFT together with merkle tree it is very good, but as a standard it does not add anything new. On ethereum they have been doing token drops with merkle tree for a long time. I think that for a new standard it is necessary to add something conceptually new, and this is not worthy of a separate standard
Hey, @purp1le!
In the world of technology, standards play a crucial role in bringing everyone together. It's not just about showcasing the novelty of ideas; rather, the primary objective is to foster consensus among all the players in the ecosystem. These standards serve as a unifying force, ensuring that we all rally behind a common technology that benefits everybody involved.
So what about indexes. like tonapi or getgems. should we index compressed collections? if yes it looks like very cheap attack to them. I can make easily collection with 100000 items, deploy it for 0.0001 TON and every index should save all items in db. but attacker even doesn't need to store all this items on his server and easily can generate it on-demand. Looks like i attacker can stream /dev/urandom to my database.
So what about indexes. like tonapi or getgems. should we index compressed collections? if yes it looks like very cheap attack to them. I can make easily collection with 100000 items, deploy it for 0.0001 TON and every index should save all items in db. but attacker even doesn't need to store all this items on his server and easily can generate it on-demand. Looks like i attacker can stream /dev/urandom to my database.
All indexers supporting this standard should come up with their own ways of filtering out malicious compressed NFT collections (for example - whitelists/blacklists, any kind of heuristics, etc) - this standard does not concern itself with that aspect.
Hey @krigga! I like the idea, but I think we should make a standard NFT compressed contract with Merkle proofs instead of Merkle trees. First of all, we should use TON possibilities and TON has a convenient proof verifying technology. Secondly, it should be much cheaper.
I started such development in my fork (currently there is no Merkle Updates implementation for updates, its just an example of how the proof can be verified). So if the community like the idea I can continue development.
I think wallet developers should support exotic cells sending in wallets, because that's a good technology that can find application in many developments. So maybe its better to wait for wallets to support this feature?
For the first time we can use proxy contracts for NFT claiming: User deploys a simple proxy contract and then sends an external message with proof to it which proxy sends to the collection contract. The cost of deployment is offset by the cheapness of proof verification with tvm built-in Merkle Proof validation.
nice
Hey how can I update my address and details because I still haven’t gain
On Sun, Dec 3, 2023 at 2:15 AM Howard Peng @.***> wrote:
Hey @krigga https://github.com/krigga! I like the idea, but I think we should make a standard NFT compressed contract with Merkle proofs instead of Merkle trees. First of all, we should use TON possibilities and TON has a convenient proof verifying technology. Secondly, it should be much cheaper.
I started such development in my fork https://github.com/yungwine/compressed-nft-contract/blob/main/contracts/collection_mp.fc (currently there is no Merkle Updates implementation for updates, its just an example of how the proof can be verified). So if the community like the idea I can continue development.
I think wallet developers should support exotic cells sending in wallets, because that's a good technology that can find application in many developments. So maybe its better to wait for wallets to support this feature?
For the first time we can use proxy contracts for NFT claiming: User deploys a simple proxy contract and then sends an external message with proof to it which proxy sends to the collection contract. The cost of deployment is offset by the cheapness of proof verification with tvm built-in Merkle Proof validation.
nice
— Reply to this email directly, view it on GitHub https://github.com/ton-blockchain/TEPs/pull/126#issuecomment-1837392794, or unsubscribe https://github.com/notifications/unsubscribe-auth/A73LUSSIRWRRMIWAGZ2SEC3YHQRHHAVCNFSM6AAAAAA23NSXUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGM4TENZZGQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
All indexers supporting this standard should come up with their own ways of filtering out malicious compressed NFT collections
This means that this is not a standard, but a set of guidelines or an example, which in fact will be supported by tonapi&getgems only, because it has no transparent indexing method for new services.
Since the current solution involves paying for indexing to specific services - this is very bad.
If a new wallet enters the ecosystem, it wants to show all the NFTs of a user, but it won't show these, because no collection will carry money to a specific wallet, but there will be disgruntled users who will argue why tonkeeper shows everything and your service don't.
And this works for any new service that would want to support such a thing. When you have atomic payment choices to support a "STANDARD". - it's not good for the ecosystem.
