Development, deployment and online process of NFT project (1)

This article will start from the contract 、 Back end 、 The front three aspects describe how to NFT Try to be fair in the offering stage , Try to make real users Mint success . The structure of the article is as follows ：

One 、 contract

NFT The most discussed issues in the sale of are summarized as the following ：

Prohibit contract invocation

If the contract allows other contracts to call Mint , That big probability will become a stage for scientists to show their operations . Even if each address is limited, the desired number of addresses can be created through the engineering contract Mint.

Means of prevention ： By judgment TX Whether the originator of the request and the source of the request received from the offering contract are consistent , Whether the call comes from other contracts . Such as Azuki Medium verification as follows ：

notes ： About  msg.sender and tx.origin  Examples of differences can be found in  Phishing with tx.originhttps://solidity-by-example.org/hacks/phishing-with-tx-origin/

White list verification

There are two common white list verification methods ：

White list of contract records

For a small number of white lists or for Merkle tree Less familiar project parties may adopt this approach , The advantage is that the logic is simple , Can be added or deleted at any time . The disadvantages are obvious , That is, the project party needs to pay the cost of modifying the whitelist data . Such as Azuki You can set the whitelist address and corresponding quantity in batch ,gas Consumption quantity can refer to  seedAllowlist Tx .

Example ：Azuki seedAllowlist

verification Merkle Proof

The most common and recommended method is contract verification Merkle Proof, Generated under the submission chain Proof Verification in the contract . This scheme has been verified many times , Can fully meet the actual needs , In addition to verifying the whitelist address, you can also add Mint Number 、 Airdrop quantity and other information .

Mint In the process, the user gets Proof The method can be used API Or will Merkle Tree Make it public for users to obtain , The following resources provide API An example of .

There are many ready-made schemes for reference , Resources are as follows ：

1. Video tutorial : OpenZeppelin Building an NFT Merkle Airdrop
2. Library: Merkletreejs Library
3. Demo: nft-merkle-drop

matters needing attention ：

1. White list address judgment ： Some project white lists are in vain and have not been verified in the contract .
2. White list Mint Quantity judgment ：Mint The quantity shall be recorded in the contract and the address shall not be used balanceOf Judge , Otherwise, the white list will be repeated Mint The problem of .

Signature parameter verification

For the public offering stage （ Non white list ）, Generally, parameter verification is used to verify whether the user data is legal , From the past cases, the following problems often arise ：

1. Uniform parameter value all users use the same parameter value for verification , This will reduce the difficulty of robot batch operation .
2. Parameter pre exposure as the name suggests, when scientists get the validation parameters in advance , There is enough time to prepare the robot .
3. Although private key leakage rarely occurs, it should also attract the attention of the project party , Do not expose the private key on the front end , The signature process and parameter generation process are executed on the back end .

Parameter verification , Recommended development mode ： The development mode recommended in the parameter verification section generates different call parameters for each address , To prevent replay attacks .

The resources ：

• Openzeppelin Of  ECDSA library: Checking Signatures On-Chain
• solidity-by-example: signature-replay

We will discuss the following two issues in the back-end chapter

Contract closed source

In order to reduce the possibility of contract being attacked or abused, the project party chooses not to disclose the contract source code , Not just in NFT Field in GameFi The same is true in the project . If this is taken as a defensive means, it can not prevent robot operation very well , Illustrate with examples ：

SuperGucci  use Contract closed source For sale , Its parameters are relatively simple, so it is inevitable to be broken by smart scientists , It's just a matter of time . Finally, scientists took away too many chips , And had to adjust the last round to be sold by lot . From the call data on the chain, we can see that the parameters are independent of the address , No other special parameters , Therefore, it is possible to replay calls with the same parameters for such contracts .

I don't recommend this way to sell , For no known IP Projects that are not open source do not give users enough confidence , Again, this is not at all Crypto .

It is a complicated problem to realize a truly fair sale , The project side may not be able to put most of its energy on the technical level . In the foreseeable future , There will be a relatively perfect sales platform, so that artists or project parties only need to pay attention to the work level , Without having to face the difficulties of technology .

NFT The sale of is just NFT Part of the project , In addition to the above precautions, there are many details worth paying attention to , For example, the setting of royalties 、 Contract and front-end and back-end testing 、NFT Metadata Deployment of 、 Randomness and rarity of attributes 、 Fairness of open graph 、 also NFT Design of pledge mechanism 、NFT Design of derivatives, etc .

I wish you all Mint To what you like NFT.