Hi @jalil welcome to Open Zeppelin Forums!
Reading material for anyone interested on the hack: https://cointelegraph.com/news/85-million-meebits-nft-project-exploited-attacker-nabs-700-000-collectible
Couldn’t just anyone do that with any publicly mintable ERC721 collection? How is it special to the meebits cryptopunk community mint?
It’s not “exactly”. It’s specific only to mintable ERC721s that rely on randomness to generate which metadata they get. Most NFTs don’t rely on random things.
A similar exploit might be done for God’s Unchained. I’d be interested to see how they handle an exploit of this nature, if they have one at all.
Let’s say for example I have an NFT creator that uses Chainlink VRF.
Edit: I was wrong about Chainlink VRF - it can help solve these exploits, check Patrick’s response below.
NOTE: I could be wrong about how Chainlink VRF works, but I think anyone can see its result after processing the VRF function.
I’m pinging @PatrickAlphaC to make sure I don’t misspeak about Chainlink VRF. And maybe he can shed some light on how these exploits can be prevented.
I make a bot that reads my rolls for my NFT metadata, and sees my VRF result in the transaction. My bot sees that this VRF roll, albeit truly random, is not what I want.
So my bot sends a transaction to cancel the minting and I can keep rerolling.
Someone could send a bunch of transactions just to try to get a desirable token but cancel the transaction if the simulated transaction in mempool returns an undesirable token, right?
Yes. That is correct.
How can one make the minting process of their NFT secure so the above doesn’t work / doesn’t make sense?
This is a complex question and a philosophical one.
Before we get into the weeds, it’s important to understand that the exploiter was burning gas at a rate of
~$20,000 an hour in gas fees This means that it only really works for expensive NFTs. What that really means, is that for God’s Unchained, it would be pointless because their NFTs there don’t cost thousands upon thousands of dollars so the exploiter would be losing his profit motive.
So a simple solution to this is to just not have your NFTs be worth the cost of gas required to exploit the results.
This isn’t really a “true” solution, but if you’re making a game, then make your game relatively inexpensive so that you aren’t exploited in this manner.
Another way to do this would be to have a blacklist. As the NFT factory owner, check a wallet’s failed transactions. If he’s failing transactions on purpose, then blacklist him from using your NFT factory. This is somewhat problematic because now someone has the power to stop a specific wallet from making NFTs. It also doesn’t stop the exploiter from doing the same thing with other wallets. It also costs you gas to add into a blacklist.
So this isn’t really a good solution either, but I think it’s a great control mechanism if you want to be more in control of your NFT factory.
Another way is to have an auxiliary controller program, such as a server running a database. If you roll an NFT with metadata - then the server updates that your wallet owns a specific NFT with the metadata. If the exploiter tries to cancel transactions to get a better roll, the server will know, and will invalidate him out of the database. So your front end program will “know” that his NFT isn’t correct and that he exploited it.
This isn’t really a solution either because it’s relying on something outside the blockchain and not a decentralized solution. But if it’s for a game, it might be usable.
A true solution might be an NFT validator contract. Somehow this validator could contain the rolls that “should” happen. I think this would require a lot of brain power, but it might be one of the ways that can work.