Web3Rover's first week assignment has ended, receiving a total of 35 submissions, accounting for about 40% of the learners, which is considered a good initial achievement of the medium threshold, low number, and high participation goals.
This assignment consists of two questions and one additional question, with a total of 10+10+5=25 points. Both 25 points and 20 points answers account for 11.4%, and there are no 0 points.
Below are the reference answers:
1. Identify an unnecessary variable in the obolus contract used for the entrance exam.#
A: mintRate. This was actually my mistake. I originally wanted to set a price to prevent people from minting a large amount on the testnet, but then I realized that there is no cost for water on the testnet, so setting it low is meaningless, and setting it high (more than the amount of water that can be obtained at once) would affect genuine learners. So in the end, I canceled the pricing but forgot to delete this variable.
Some students answered ObolusSliver's ID for this question, but I don't know why. Although this variable doesn't need to be defined, using it directly in the code is considered using a magic number, which is not recommended.
2. Explain how the obolus contract ensures that a wallet can only have one.#
A: There are actually three places for this question, so only one person actually answered all of them (but I also consider it correct if the second one is not answered).
First place: require(balanceOf(msg.sender, ObolusSliver) == 0, "You already have one Obolus.");
This ensures that the number of ObolusSliver in the wallet is 0 before minting.
The key point here is ERC1155's balanceOf(address, tokenId), which is what I mentioned earlier, you can directly use 0, but using a magic number is not recommended.
Second place: require(amount == 1, "Wrong amount. Should be 1");
This ensures that only one can be minted each time.
Third place: require(address(0) == from, "You can not give your Obolus to others.");
This is the most easily overlooked one in the answers, in _beforeTokenTransfer. Think about it carefully, with only the above two requirements, it is not possible to prevent the situation where "after minting, the token is transferred to another wallet that already has a token, resulting in a holding of more than 1".
So this line of code directly restricts anyone from transferring the token except for the 0 address. As for why it is restricted to the 0 address, it is actually a good thinking question - have you ever thought about where the minting of this NFT comes from?
3. (Additional question) Explain why ERC1155 is not suitable for PFP projects with different traits.#
There are actually many things that can be said about this question, but the core is that ERC1155 uses a double-layer mapping to implement a contract that can store multiple types of tokens, where tokens refer to both NFTs and FTs.
The biggest difference between the tokenID of ERC1155 and ERC721 is that in 1155, one tokenID represents one type of token. In 721, because there is only one type of token in total, the tokenID represents the number of each individual token.
In this exam, 1155 is used, and you can see that there is only one tokenID, ObolusSliver (which is 0), which represents that this erc1155 only contains one type of token. And diving into the ObolusSliver token, each token itself does not have its own number, meaning it is no different from others. This design is actually to be compatible with FTs, where under the default erc1155 interface, FTs and NFTs can behave the same.
In summary, ERC1155 specifies multiple types of tokens, and the tokenID is used to mark different types of tokens. Even if each token of the same type, including NFTs, has no difference in numbering. On the other hand, ERC721 can only contain one type of token, and the tokenID is used to mark the number of each individual token.
Ultimately, the trait system of 721 relies entirely on the tokenID to allocate metadata. This difference in design also means that in erc1155, because tokens of the same type have no difference in numbering by default, there is no way to assign different metadata to each token of the same type.
Of course, none of this is absolute. In fact, developers can add their own logic to record the ID of each token in each type under 1155, but it requires more work and more gas consumption.
Our official Twitter: