Popular Science | Technical Explanation of the NFT Minting and Purchasing Process: How Do Scientists Snatch Up NFTs?

Author: @iamcatcher

This article is based on my recent learning and discussions with friends in the group, serving as a record, and concludes with my thoughts on the current state of the NFT industry. As someone new to blockchain and Ethereum programming, I may make mistakes, and I welcome corrections and exchanges.

NFT Purchase Process

In simple terms, the purchase process involves your wallet interacting with the NFT contract. You transfer 0.176 ETH from your wallet to the contract, call the contract's mint method, and generate two NFT tokens, which are then transferred to your wallet, allowing you to obtain the NFT.

For more information about NFT contracts, you can refer to the following article: Technical Sharing Behind NFT and OpenSea Transactions---Mirror

Detailed Explanation of the NFT Purchase Process

Click the mint button on the official website of the project, and the detailed end-to-end interaction process from the browser to the Ethereum network is opened:

NFT Purchase Process

1. Click the Mint Button

Everyone logs into the project website, connects their wallet on Chrome, and then clicks the mint button. The JavaScript code on the webpage generates raw transaction data based on the project's mint price, contract address, etc., which mainly includes the following key fields:

2. TX Signing

The webpage code interacts with Metamask, prompting a window for you to confirm the transaction. After clicking confirm, Metamask uses your wallet's private key to sign the transaction, ensuring that this transaction is authorized by you. The Ethereum network will then verify it.

3. Send TX to Node for Verification

The transaction TX is sent by Metamask to Metamask's Ethereum node (default configuration), which verifies the TX to ensure the transaction is not counterfeit.

4. Broadcast TX to the Ethereum Network

The transaction TX is sent to neighboring nodes in the Ethereum network and then broadcast to adjacent nodes. At this point, your transaction can be viewed on etherscan.io, with a status of pending.

5. Miner Node Receives TX

Miner nodes will place the synchronized TX into a place called Txpool/Mempool, which is crucial for many processes and needs to be elaborated on:

Txpool Code Flow (using a diagram from Ethereum source code analysis of txpool)

The data in Txpool mainly comes from:

Local submissions, which are transactions submitted by third-party applications through the RPC service of the local Ethereum node;

Remote synchronization, which refers to synchronizing transaction data from other Ethereum nodes to the local node through broadcasting.

Txpool is divided into two queues: Queue and Pending. Newly received TX will first be placed in the Queue based on rules, and then added to the Pending queue waiting to be mined into a new block.

The main rules are as follows:

1) Prioritize TX with higher Gas prices. 2) Local TX are prioritized over remote synchronization. 3) Each node sets a minimum Gas price; remote TX below this value will be discarded.

TX in Pending is obtained and verified by the Miner module for mining; after successful mining, it is written into a block and broadcast. The Miner takes the transaction as a copy, and TX in Txpool does not decrease. TX is only removed from Txpool after being written into the chain.

TX with too low Gas will remain stuck in Txpool without being processed; you need to increase Gas for it to be processed.

For detailed code analysis, you can refer to the article on Ethereum source code analysis of txpool.

Gas War: When popular transactions occur, everyone competes to raise Gas fees to ensure their TX is processed first.

6. Miner Packages TX into a Block

After selecting TX, miners start mining and broadcast the solution to a block to the Ethereum network.

7. Block is Verified

After verification by other miner nodes, the block is officially added to the chain, and the results of our TX can be viewed on etherscan.io.

8. TX Status Synchronization

Relevant statuses are returned locally and can be queried on Metamask.

Reference Documents:

Life Cycle of an Ethereum Transaction

Transaction lifecycle on the Ethereum blockchain

The Influence Factors on Ethereum Transaction Fees

How Contracts are Executed

In simple terms, the transactions we send are converted into a Message object passed to the EVM, which generates a Contract object based on the Message for subsequent execution. The Data we input is converted into the contract's input to call the mint function.

For a detailed introduction to EVM, refer to the following documents:

easy-evm

learnblockchain.cn

NFT Presale and Public Sale

Presales are only available for specific users, while public sales are open to everyone.

Here, we mainly need to address two technical questions:

1. How to restrict specific wallets from minting?
2. How is the state switched between presale and public sale?

Whitelist Mechanism

The whitelist is commonly implemented using Merkle trees. In simple terms, all whitelisted wallet addresses are treated as leaf nodes of the Merkle tree, generating a Root hash. The contract only needs to store the Root hash value, and when calling the mint function, the webpage's JS code generates proof (the hash of the parent node of the address) based on the wallet address, allowing the contract to verify whether the address belongs to the whitelist.

Taking the C01 contract as an example:

0x6fd053bff10512d743fa36c859e49351a4920df6

During the presale and public sale, the hash is updated through SetRoot (C01 used the whitelist method for both sales, while the public sale adopted a capital verification lottery method).

For detailed principles and code, refer to the article: Using Merkle Trees for NFT Whitelists.

Sales State Switching

Two common methods:

1) By determining a time point in the contract, for example, starting public sales at 2022-01-01 18:00 UTC. 2) By state judgment, setting a state variable in the contract, such as in the XRC contract, judging the Status.PublicSale state, which is set by calling SetStatus in the contract.

How Scientists Snatch NFTs

Scientists use programs to snatch NFTs, employing various means to ensure their transaction TX is packaged by miners before others, completing the NFT mint before it sells out. Scientists are also perfectionists, and the ideal outcome is for their TX to appear first in the block that meets the public sale status, also known as snatching Block0.

The two scenarios for Block0 are shown in the image below. Achieving Block0 can also avoid the Gas war that occurs during subsequent purchases, reducing the cost of snatching. However, it is becoming increasingly competitive, and Block0 can also experience Gas wars. For example, in the XRC public sale, with fewer than 200 available, the number of scientist TX entering Block0 exceeded 200, and many did not succeed due to low Gas.

Block0 in two scenarios

The methods used by scientists can be summarized in the following three points:

1. Lower Information Acquisition Delay

Similar to financial quantitative trading, funds aim for lower communication latency between their servers and exchanges. The blockchain is similar; for example, CEX users connect to the nearest centralized exchange servers. NFT minting and DeFi transactions occur within the Ethereum network, where everyone seeks faster Ethereum Nodes or connections to large mining pools to monitor pending TX in Txpool more quickly and obtain the necessary information for timely execution.

2. Shorter Transaction Path

1) As seen in the TX interaction process above, scientists will directly interact with the NFT contract through their programs. 2) By deploying their contracts on-chain, scientists can interact with the NFT contract through private contracts. Although private contracts require external TX to trigger, they can batch purchase, especially suitable for NFTs that do not limit mint quantities. (Increasingly, NFTs are restricting calling parties to contracts.)

3. Batch Submission of Transactions

In addition to minting through private contracts mentioned above, if the project limits the number of mints per address, multiple TX can be packaged together using Flashbots.

Contract Minting

An example of a contract snatching is after the public sale of YOKAI. Scientists used private contracts to snatch a total of 750 mints. For details, see TX.

The YOKAI contract code does not limit how many can be minted by one address, only restricting that a single TX can mint 2 at a time. Thus, it was fully snatched by scientists.

Tool Flashbots

For a detailed explanation of Flashbots, see Wei's excellent introduction and the official documentation: Flashbots: How to Withdraw Assets or Interact with Contracts from a Wallet Without ETH---Mirror.

Using Flashbots has several benefits:

1) You can batch package TX together for submission and control the order of TX packaging. 2) TX submitted through Flashbots do not appear in Txpool and are only visible on-chain after being processed. This provides TX privacy, which is why many DeFi quantitative trading platforms promote their integration with Flashbots. (I believe this is only temporary; as Flashbots become widely used, TX submitted through Flashbots will still be monitored.) 3) If minting fails through Flashbots, no Gas fees will be charged.

Taking the public sale of Cold Rabbit XRC as an example of Flashbots snatching:

Boss Yi tweeted that the public sale would not be for scientists, but the result was that in block=14020984, Block0 was resolved, and all scientists snatched it.

The setStatus TX sent by the project party was monitored in Txpool at 14020982.

Then a scientist packaged the setStatus TX and their mint TX together using Flashbots and sent it to the miners. Here, the scientist placed the setStatus TX first, even though its Gas was low, and positioned their mint TX afterward. Ultimately, the TX was included in block 984.

Flashbots packaging query link:

Burning Blocks

In simple terms, this means continuously sending TX; the more you send, the higher the probability of successful minting, and you might even get lucky and squeeze into Block0. The issue with this approach is that it consumes a lot of Gas fees, making it a play for those with deep pockets. Burning blocks generally consider the start time, interval between each TX, number of submissions, Gas fees, etc., which everyone usually considers based on project timing, monitoring pending TX, and the speed of block production on-chain.

During the public sale of Cold Rabbit, many scientists successfully used the burning block method to snatch NFTs; you can check this wallet.

How to Prevent Scientists

With the emergence of scientists snatching NFTs, more and more projects are starting to use various methods to prevent scientists from snatching. The essence of these methods is to restrict scientists from directly calling the contract to mint, allowing only selected individuals to mint.

1. Sale Exclusively Through Whitelist

Projects use a whitelist mechanism for all sales, allowing the project party to filter out those they believe truly appreciate the project.

However, where there are rules, there are countermeasures. With levels and invitation numbers, chatbots and studios have emerged to sell invitation slots; for creative art, people are found on Taobao to paint; now it has developed into time-limited invitations to join Discord; and various games like guessing riddles and completing tasks.

The project party is racking their brains to outsmart the studios that are brushing whitelists, while ordinary NFT players are being toyed with by various rules.

2. Public Sale Using Capital Verification Lottery

For example, during the NFT public sale, wallets are required to verify a certain amount of ETH in advance, and then a lottery system is used to provide a winning list. However, many project parties are unwilling to create a 1:1 lottery system for convenience, resulting in a significant overselling of the public sale list, leading to everyone snatching.

3. Server-Side Signature Verification for Minting

Similar to the recent popular approach of HAPE, the public NFT contract restricts minting to only a private, closed-source contract. The closed-source contract interacts with the project party's backend server, which, from a technical perspective, seems to conflict with the centralized thinking of web2 and the decentralized philosophy of web3.

Future Development of NFTs

Those who have worked on whitelists feel that the current NFT industry is unhealthy, but the NFT industry is still in its early stages. Where there are problems, there will be a market, and someone will surely emerge to solve them.

NFT sales need to be public, notarized, and transparent. I believe the solution can draw from two familiar scenarios in real life:

1. New stock issuance, where exchanges set thresholds for account trading duration, capital verification, etc., followed by a lottery for issuance.
2. Purchasing Moutai on JD.com, where the JD platform conducts account verification and guarantees fairness in purchasing.

Both scenarios ensure fairness through the authority of the platform, but in web3, there should be new solutions based on blockchain contracts to achieve similar functions, just like the various trading protocols in the current DeFi market. In the near future, NFT sales protocols may emerge, providing a fair, notarized, and transparent sales model. I am still learning and thinking about how to do this, and I welcome everyone’s guidance and discussion.

In the future, NFT project parties should connect to an NFT launch platform, allowing them to focus more on artistic creation and the evolution of their roadmap, while investors concentrate on the project's content and prospects, with the launch platform solving various issues related to NFT sales through technology.