Merge pull request #2 from Mosamorphing/quat-branch

Quat branch

Languages/en/31_ERC20_en/readme.md

@@ -20,7 +20,7 @@ Codes and tutorials are open source on GitHub: [github.com/AmazingAng/WTFSolidit
 
 -----
 
-In this lecture, we will introduce the ERC20 token standard on Ethereum and issue our own test tokens.
+In this lecture, we will introduce the ERC20 token standard on Ethereum and issue our test tokens.
 
 ## ERC20
 
@@ -33,7 +33,7 @@ ERC20 is a token standard on Ethereum, which originated from the `EIP20` propose
 - Token Information (optional): name, symbol, decimal
 
 ## IERC20
-`IERC20` is the interface contract of the `ERC20` token standard, which specifies the functions and events that `ERC20` tokens need to implement. The reason for defining an interface is that with the standard, there are universal function names, input and output parameters for all `ERC20` tokens. In the interface functions, only the function name, input parameters, and output parameters need to be defined, and it does not matter how the function is implemented internally. Therefore, the functions are divided into two contents: internal implementation and external interface, focusing on implementation and agreement of shared data between interfaces. This is why we need two files `ERC20.sol` and `IERC20.sol` to implement a contract.
+`IERC20` is the interface contract of the `ERC20` token standard, which specifies the functions and events that `ERC20` tokens need to implement. The reason for defining an interface is that with the standard, there are universal function names and input and output parameters for all `ERC20` tokens. In the interface functions, only the function name, input parameters, and output parameters need to be defined, and it does not matter how the function is implemented internally. Therefore, the functions are divided into two contents: internal implementation and external interface, focusing on the implementation and agreement of shared data between interfaces. This is why we need two files `ERC20.sol` and `IERC20.sol` to implement a contract.
 
 ### Event
 
@@ -244,4 +244,4 @@ The account information is shown on the left like below image, and the details o
 
 ## Summary
 
-In this lesson, we learned about the `ERC20` standard and its implementation on the Ethereum network, and issued our own test token. The `ERC20` token standard proposed at the end of 2015 greatly lowered the threshold for issuing tokens on the Ethereum network and ushered in the era of `ICO`. When investing, carefully read the project's token contract to effectively avoid risks and increase investment success rate.
+In this lesson, we learned about the `ERC20` standard and its implementation on the Ethereum network, and issued our own test token. The `ERC20` token standard proposed at the end of 2015 greatly lowered the threshold for issuing tokens on the Ethereum network and ushered in the era of `ICO`. When investing, carefully read the project's token contract to effectively avoid risks and increase investment success rate.

Languages/en/32_Faucet_en/readme.md

@@ -36,7 +36,7 @@ Here, we will implement a simplified version of an `ERC20` faucet. The logic is
 
 We define `3` state variables in the faucet contract:
 
-- `amountAllowed` sets the amount of tokens that can be claimed per request (default value is `100`, not 100 tokens as tokens may have decimal places).
+- `amountAllowed` sets the number of tokens that can be claimed per request (default value is `100`, not 100 tokens as tokens may have decimal places).
 - `tokenContract` stores the address of the `ERC20` token contract.
 - `requestedAddress` keeps track of the addresses that have already claimed tokens.
 
@@ -103,4 +103,4 @@ function requestTokens() external {
 
 ## Conclusion
 
-In this lecture, we introduced the history of token faucets and the `ERC20` faucet contract. Where do you think the next BTC faucet will be?
+In this lecture, we introduced the history of token faucets and the `ERC20` faucet contract. Where do you think the next BTC faucet will be?

Languages/en/33_Airdrop_en/readme.md

@@ -48,7 +48,7 @@ The logic of the airdrop contract is simple: by using a loop, a single transacti
    - `_addresses`: Array of user addresses receiving the airdrop (`address[]` type)
    - `_amounts`: Array of airdrop amounts that correspond to the quantity of each address in `_addresses` (`uint[]` type)
 
-   This function contains `2` checks: The first `require` checks if the length of `_addresses` array is equal to the length of `_amounts` array . The second `require` checks if the authorization limit of the airdrop contract is greater than the total amount of tokens to be airdropped.
+   This function contains `2` checks: The first `require` checks if the length of the `_addresses` array is equal to the length of the `_amounts` array. The second `require` checks if the authorization limit of the airdrop contract is greater than the total amount of tokens to be airdropped.
 
 ```solidity
 /// @notice Transfer ERC20 tokens to multiple addresses, authorization is required before use
@@ -132,4 +132,4 @@ function multiTransferETH(
 
 ## Conclusion
 
-In this lesson, we introduced how to use `solidity` to write an `ERC20` token airdrop contract, greatly increasing the efficiency of airdrops. The biggest airdrop I ever received was from `ENS`, how about you?
+In this lesson, we introduced how to use `solidity` to write an `ERC20` token airdrop contract, greatly increasing the efficiency of airdrops. The biggest airdrop I ever received was from `ENS`, how about you?

Languages/en/34_ERC721_en/readme.md

@@ -131,7 +131,7 @@ interface IERC721 is IERC165 {
 
 ## IERC721Receiver
 
-If a contract does not implement the relevant functions of `ERC721`, the incoming NFT will be stuck and unable to be transferred out, causing a loss of the token. In order to prevent accidental transfers, `ERC721` implements the `safeTransferFrom()` function, and the target contract must implement the `IERC721Receiver` interface in order to receive `ERC721` tokens, otherwise it will `revert`. The `IERC721Receiver` interface only includes an `onERC721Received()` function.
+If a contract does not implement the relevant functions of `ERC721`, the incoming NFT will be stuck and unable to be transferred out, causing a loss of the token. In order to prevent accidental transfers, `ERC721` implements the `safeTransferFrom()` function, and the target contract must implement the `IERC721Receiver` interface in order to receive `ERC721` tokens, otherwise, it will `revert`. The `IERC721Receiver` interface only includes an `onERC721Received()` function.
 
 ```solidity
 // ERC721 receiver interface: Contracts must implement this interface to receive ERC721 tokens via safe transfers.
@@ -244,13 +244,13 @@ contract ERC721 is IERC721, IERC721Metadata{
         return _balances[owner];
     }
 
-    // Implements the ownerOf function of IERC721, which uses `_owners` variable to check `tokenId`'s owner.
+    // Implements the ownerOf function of IERC721, which uses the `_owners` variable to check `tokenId`'s owner.
     function ownerOf(uint tokenId) public view override returns (address owner) {
         owner = _owners[tokenId];
         require(owner != address(0), "token doesn't exist");
     }
 
-    // Implements the isApprovedForAll function of IERC721, which uses `_operatorApprovals` variable to check whether `owner` address's NFTs are authorized in batch to be held by another `operator` address.    
+    // Implements the isApprovedForAll function of IERC721, which uses the `_operatorApprovals` variable to check whether the `owner` address's NFTs are authorized in batch to be held by another `operator` address.    
     function isApprovedForAll(address owner, address operator)
         external
         view
@@ -260,19 +260,19 @@ contract ERC721 is IERC721, IERC721Metadata{
         return _operatorApprovals[owner][operator];
     }
 
-    // Implements the setApprovalForAll function of IERC721, which approves all holding tokens to `operator` address. Invokes `_setApprovalForAll` function.
+    // Implements the setApprovalForAll function of IERC721, which approves all holding tokens to the `operator` address. Invokes `_setApprovalForAll` function.
     function setApprovalForAll(address operator, bool approved) external override {
         _operatorApprovals[msg.sender][operator] = approved;
         emit ApprovalForAll(msg.sender, operator, approved);
     }
 
-    // Implements the getApproved function of IERC721, which uses `_tokenApprovals` variable to check authorized address of `tokenId`.
+    // Implements the getApproved function of IERC721, which uses the `_tokenApprovals` variable to check the authorized address of `tokenId`.
     function getApproved(uint tokenId) external view override returns (address) {
         require(_owners[tokenId] != address(0), "token doesn't exist");
         return _tokenApprovals[tokenId];
     }
      
-    // The approve function, which updates `_tokenApprovals` variable to approve `to` address to use `tokenId` and emits an Approval event.
+    // The approve function, which updates the `_tokenApprovals` variable to approve `to` address to use `tokenId` and emits an Approval event.
     function _approve(
         address owner,
         address to,
@@ -391,7 +391,7 @@ contract ERC721 is IERC721, IERC721Metadata{
     }
 
     /** 
-     * The mint function, which updates `_balances` and `_owners` variables to mint `tokenId` and transfers it to `to`. It emits an Transfer event.
+     * The mint function, which updates `_balances` and `_owners` variables to mint `tokenId` and transfers it to `to`. It emits a Transfer event.
      * This mint function can be used by anyone, developers need to rewrite this function and add some requirements in practice.
      * Requirements: 
      * 1. `tokenId` must not exist.
@@ -494,12 +494,12 @@ contract WTFApe is ERC721{
 
 With the `ERC721` standard, issuing NFTs on the `ETH` chain has become very easy. Now, let's issue our own NFT.
 
-After compiling the `ERC721` contract and the `WTFApe` contract in `Remix` (in order), click the button in the deployment column, enter parameters of the constructor function , set `name_` and `symbol_` to `WTF`, and then click the `transact` button to deploy.
+After compiling the `ERC721` contract and the `WTFApe` contract in `Remix` (in order), click the button in the deployment column, enter the parameters of the constructor function, set `name_` and `symbol_` to `WTF`, and then click the `transact` button to deploy.
 
 ![How to emphasize NFT information](./img/34-1.png)
 ![Deploy contract](./img/34-2.png)
 
-This way, we have created the `WTF` NFT. We need to run the `mint()` function to mint some tokens for ourselves. In the `mint` function panel, click the right button to input the account address and token id, and then click the `mint` button to mint the `0`-numbered `WTF` NFT for ourselves.
+This way, we have created the `WTF` NFT. We need to run the `mint()` function to mint some tokens for ourselves. In the `mint` function panel, click the right button to input the account address and token ID, and then click the `mint` button to mint the `0`-numbered `WTF` NFT for ourselves.
 
 You can click the Debug button on the right to view the logs below.
 
@@ -528,7 +528,7 @@ interface ERC721TokenReceiver {
 }
 ```
 
-Expanding into the world of programming languages, whether it's Java's interface or Rust's Trait (of course, in solidity, it's more like a library than a trait), whenever it relates to interfaces, it implies that an interface is a collection of certain behaviors (in solidity, interfaces are equivalent to a collection of function selectors). If a certain type implements a certain interface, it means that the type has a certain functionality. Therefore, as long as a certain contract type implements the above `ERC721TokenReceiver` interface (specifically, it implements the `onERC721Received` function), the contract type indicates to the outside world that it has the ability to manage NFTs. Of course, the logic of operating NFTs is implemented in other functions of the contract.
+Expanding into the world of programming languages, whether it's Java's interface or Rust's Trait (of course, in solidity, it's more like a library than a trait), whenever it relates to interfaces, it implies that an interface is a collection of certain behaviours (in solidity, interfaces are equivalent to a collection of function selectors). If a certain type implements a certain interface, it means that the type has a certain functionality. Therefore, as long as a certain contract type implements the above `ERC721TokenReceiver` interface (specifically, it implements the `onERC721Received` function), the contract type indicates to the outside world that it has the ability to manage NFTs. Of course, the logic of operating NFTs is implemented in other functions of the contract.
 
 When executing `safeTransferFrom` in the ERC721 standard, it will check whether the target contract implements the `onERC721Received` function, which is an operation based on the `ERC165` idea.
 
@@ -587,7 +587,7 @@ The calculation of **0x5b5e139f** is:
 IERC721Metadata.name.selector ^ IERC721Metadata.symbol.selector ^ IERC721Metadata.tokenURI.selector
 ```
 
-How does the ERC721.sol implemented by Solamte fulfill these features required by `ERC165`?
+How does the ERC721.sol implemented by Solamte fulfil these features required by `ERC165`?
 
 ```solidity
 function supportsInterface(bytes4 interfaceId) public view virtual returns (bool) {
@@ -619,4 +619,4 @@ function supportsInterface(bytes4 interfaceId) public view virtual returns (bool
 **Elegance, conciseness, and scalability are maximized.**
 
 ## Summary
-In this lesson, I introduced the `ERC721` standard, interface, and implementation, and added English comments to the contract code. We also used `ERC721` to create a free `WTF APE` NFT, with metadata directly called from `BAYC`. The `ERC721` standard is still evolving, with the currently popular versions being `ERC721Enumerable` (improving NFT accessibility) and `ERC721A` (saving `gas` in minting).
+In this lesson, I introduced the `ERC721` standard, interface, and implementation, and added English comments to the contract code. We also used `ERC721` to create a free `WTF APE` NFT, with metadata directly called from `BAYC`. The `ERC721` standard is still evolving, with the currently popular versions being `ERC721Enumerable` (improving NFT accessibility) and `ERC721A` (saving `gas` in minting).

Languages/en/35_DutchAuction_en/readme.md

@@ -20,7 +20,7 @@ Codes and tutorials are open source on GitHub: [github.com/AmazingAng/WTFSolidit
 
 ----
 
-In this lecture, I will introduce the Dutch Auction and explain how to issue a `NFT` using the `ERC721` standard through a simplified version of the `Azuki` Dutch Auction code.
+In this lecture, I will introduce the Dutch Auction and explain how to issue an `NFT` using the `ERC721` standard through a simplified version of the `Azuki` Dutch Auction code.
 
 ## Dutch Auction
 
@@ -55,7 +55,7 @@ contract DutchAuction is Ownable, ERC721 {
 There are a total of `9` state variables in the contract, of which `6` are related to the auction. They are:
 
 - `COLLECTION_SIZE`: Total number of NFTs.
-- `AUCTION_START_PRICE`: Starting price of the Dutch auction, also the highest price.
+- `AUCTION_START_PRICE`: Starting price of the Dutch auction, is also the highest price.
 - `AUCTION_END_PRICE`: Ending price of the Dutch auction, also the lowest price/floor price.
 - `AUCTION_TIME`: Duration of the auction.
 - `AUCTION_DROP_INTERVAL`: Time interval when the price drops.
@@ -115,7 +115,7 @@ If `block.timestamp` is between the start and end times, the current decay price
 
 - User auctions and mints `NFT`: Users participate in a Dutch auction and mint `NFT` by calling the `auctionMint()` function to pay `ETH`.
 
-First, the function checks if the auction has started or if the number of `NFTs` has exceeded the limit. Then, the contract calculates the auction cost based on the number of minted `NFTs` and using the `getAuctionPrice()` function. It also checks if the user has enough `ETH` to participate. If the user has enough `ETH`, the contract mints `NFTs` and refunds any excess `ETH`. Otherwise, the transaction is reverted.
+First, the function checks if the auction has started or if the number of `NFTs` has exceeded the limit. Then, the contract calculates the auction cost based on the number of minted `NFTs` and uses the `getAuctionPrice()` function. It also checks if the user has enough `ETH` to participate. If the user has enough `ETH`, the contract mints `NFTs` and refunds any excess `ETH`. Otherwise, the transaction is reverted.
 
 ```solidity
     // the auction mint function
@@ -171,4 +171,4 @@ First, the function checks if the auction has started or if the number of `NFTs`
 
 ## Summary
 
-In this lecture, we introduced the Dutch auction and explained how to issue `ERC721` standard `NFT` through `Dutch auction` using a simplified version of the `Azuki` Dutch auction code. The most expensive `NFT` I auctioned was a piece of music `NFT` by musician `Jonathan Mann`. What about you?
+In this lecture, we introduced the Dutch auction and explained how to issue `ERC721` standard `NFT` through `Dutch auction` using a simplified version of the `Azuki` Dutch auction code. The most expensive `NFT` I auctioned was a piece of music `NFT` by musician `Jonathan Mann`. What about you?

Languages/en/36_MerkleTree_en/readme.md

@@ -14,9 +14,9 @@ Recently, I have been reviewing solidity in order to consolidate some details an
 
 Welcome to follow me on Twitter: [@0xAA_Science](https://twitter.com/0xAA_Science)
 
-Welcome to join the WTF Scientist community, which includes methods for adding WeChat groups: [link](https://discord.gg/5akcruXrsk)
+Welcome to the WTF Scientist community, which includes methods for adding WeChat groups: [link](https://discord.gg/5akcruXrsk)
 
-All code and tutorials are open source on Github (1024 stars will issue course certification, 2048 stars will issue community NFTs): [github.com/AmazingAng/WTFSolidity](https://github.com/AmazingAng/WTFSolidity)
+All code and tutorials are open source on GitHub (1024 stars will issue course certification, 2048 stars will issue community NFTs): [github.com/AmazingAng/WTFSolidity](https://github.com/AmazingAng/WTFSolidity)
 
 -----
 
@@ -204,4 +204,4 @@ If we call the `mint` function again at this point, although the address can pas
 
 In this lesson, we introduced the concept of `Merkle Tree`, how to generate a simple `Merkle Tree`, how to use smart contracts to verify `Merkle Tree`, and how to use it to distribute `NFT` whitelist.
 
-In practical use, complex `Merkle Tree` can be generated and managed using the `merkletreejs` library in Javascript, and only one root value needs to be stored on the chain, which is very gas-efficient. Many project teams choose to use `Merkle Tree` to distribute the whitelist.
+In practical use, complex `Merkle Tree` can be generated and managed using the `merkletreejs` library in Javascript, and only one root value needs to be stored on the chain, which is very gas-efficient. Many project teams choose to use `Merkle Tree` to distribute the whitelist.