Factory Contract Development

Author of this section: @mocha.wiz @Fish

this talk we will guide you through Factory.sol development of contracts.

Contract Introduction

in our curriculum design PoolManager the contract was inherited. Factory contracts, in the development of Solidity smart contracts, such inheritance is more just for the organization of code, and there will only be one contract after the final contract is released on the chain. In theory, we can also put Factory contracts and PoolManager write to a .sol file, but for the readability and maintainability of the code, we still chose the inheritance approach.

In addition Factory the contract mainly refers UniswapV3Factory.sol the design, it is necessary. And PoolManager The logic in the contract is only to provide DApp with an interface to obtain all transaction pool information, such an interface can be provided through the server, it is not necessary.

As shown in the following figure:

Factory the main function of the contract is to create a trading pool ( Pool ),WTFSwap gets a Factory contracts (also PoolManager contract, which it inherited Factory ), and different trading pairs include the same trading pair as long as the price upper and lower limits and fees are different to create a new trading pool. And Factory contracts are primarily used to create Pool of the contract. Through this course, you will learn how to create contracts through contracts, as well as access to the development of contract events that we have simply learned in our previous basic courses, as well as some new syntax in other Solidity.

Contract Development

the complete code is in demo-contract/contracts/wtfswap/Factory.sol in.

1. Create a trading pool

in the previous curriculumIn, we have created a mapping (If you haven't created it yet, you can do it now Pool.sol add this line):

mapping(address => mapping(address => address[])) public pools;

next we perfect createPool method, create a contract and populate its address to pools medium:

function sortToken(
    address tokenA,
    address tokenB
) private pure returns (address, address) {
    return tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
}

function createPool(
    address tokenA,
    address tokenB,
    int24 tickLower,
    int24 tickUpper,
    uint24 fee
) external override returns (address pool) {
    // validate token's individuality
    require(tokenA != tokenB, "IDENTICAL_ADDRESSES");

    // Declare token0 and token1
    address token0;
    address token1;

    // sort token, avoid the mistake of the order
    (token0, token1) = sortToken(tokenA, tokenB);

    // save pool info
    parameters = Parameters(
        address(this),
        tokenA,
        tokenB,
        tickLower,
        tickUpper,
        fee
    );

    // generate create2 salt
    bytes32 salt = keccak256(
        abi.encode(token0, token1, tickLower, tickUpper, fee)
    );

    // create pool
    pool = address(new Pool{salt: salt}());

    // save created pool
    pools[token0][token1].push(pool);

    // delete pool info
    delete parameters;
}

it should be noted that you need to introduce it in the head. Pool contract:

import "./Pool.sol ";

you can see that we're through pool = address(new Pool{salt: salt}()); this line of code creates a new Pool contract, and through pools[token0][token1].push(pool); save its address pools in.

It should be noted here that we have added salt to use CREATE2 the advantage of creating a contract is that the address of the contract created is predictable, and the logic of address generation is. New address = hash("0xFF", creator address, salt, initcode) .

And in our code salt is through abi.encode(token0, token1, tickLower, tickUpper, fee) calculated, the advantage is that as long as we know token0 and token1 address, and tickLower , tickUpper and fee with these three parameters, we can predict the address of the new contract. In our tutorial design, this does not seem to be useful. But in the actual DeFi scenario, this will bring many benefits. For example, other contracts can calculate us directly. Pool the address of the contract so that it can be developed and Pool more features of contract interaction.

Of course, this also poses a problem, which prevents us from passing parameters through the contract's constructor. Pool the initialization parameter of the contract, as that would result in the new address calculation above. initcode changes occur. So we introduced in the code parameters this variable to hold Pool the initialization parameters of the contract so that we can Pool passed in the contract parameters to get the initialization parameters. This we will be in the back Pool more specific development in the contract course.

2. Check whether the trading pool already exists before creating it.

We are in createPool add a code to check if the trading pool already exists, you can use it. IPool interface to obtain information about the trading pool through the contract address of the trading pool:

// get current all pools
address[] memory existingPools = pools[token0][token1];

// check if the pool already exists
for (uint256 i = 0; i < existingPools.length; i++) {
    IPool currentPool = IPool(existingPools[i]);

    if (
        currentPool.tickLower() == tickLower &&
        currentPool.tickUpper() == tickUpper &&
        currentPool.fee() == fee
    ) {
        return existingPools[i];
    }
}

in Uniswap V3 the code is passed. require(getPool[token0][token1][fee] == address(0)); check, but because our course design has a price upper and lower limit for each trading pair, we need to use an array to store all possible trading pools under a trading pair, and then loop through it to check if it already exists.

Of course, in the development of smart contracts, you should try to avoid loops like this. , because this will increase the gas cost of the contract. Is there a better plan for this demand? You can think about it, and we will start it in the following chapter on contract optimization. It should be noted that in the process of contract development, contract optimization should be the awareness that developers should have, so that your contract can run more efficiently and safely on the chain. Because of the teaching nature of this course and the limited level of the author, it is inevitable that there are omissions. Please do not use the code directly in the production environment. If you have any better suggestions, you are also welcome to tell us by submitting ISSUE or Pull Request to improve the course together.

3. Events

finally, we add an event to notify DApp that the transaction pool has been created:

emit PoolCreated(
    token0,
    token1,
    uint32(existingPools.length),
    tickLower,
    tickUpper,
    fee,
    pool
);

another thing to note is that although we are in createPool returned in the function pool However, when it comes to the method of contract writing, the real creation is successful only after the transaction is packed into the block, so in DApp you need to monitor the creation of the transaction pool through events, and you cannot judge whether the creation is successful by reading the return value. The return value is usually only used when simulating transactions.

4. Get the trading pool

finally, we add getPool method, which will be in the future. SwapRouter it is used in the contract:

function getPool(
    address tokenA,
    address tokenB,
    uint32 index
) external view override returns (address) {
    require(tokenA != tokenB, "IDENTICAL_ADDRESSES");
    require(tokenA != address(0) && tokenB != address(0), "ZERO_ADDRESS");

    // Declare token0 and token1
    address token0;
    address token1;

    (token0, token1) = sortToken(tokenA, tokenB);

    return pools[tokenA][tokenB][index];
}

contract Testing

before doing end-to-end testing, we should try our best to ensure that the logic of the contract is correct through as perfect unit testing as possible, and the security of the contract is very important, because once the contract is released, the logic cannot be changed, and any coding errors can have disastrous consequences.

Hardhat has a built-in unit test scheme, which we have in test new under directory wtfswap/Factory.ts file:

import { loadFixture } from "@nomicfoundation/hardhat-toolbox-viem/network-helpers";
import { expect } from "chai";
import hre from "hardhat";

describe("Factory", function () {
  async function deployFixture() {
    const factory = await hre.viem.deployContract("Factory");
    const publicClient = await hre.viem.getPublicClient();
    return {
      factory,
      publicClient,
    };
  }

  it("createPool", async function () {
    const { factory, publicClient } = await loadFixture(deployFixture);
    const tokenA: `0x${string}` = "0xEcd0D12E21805803f70de03B72B1C162dB0898d9";
    const tokenB: `0x${string}` = "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984";

    const hash = await factory.write.createPool([
      tokenA,
      tokenB,
      1,
      100000,
      3000,
    ]);
    await publicClient.waitForTransactionReceipt({ hash });
    const createEvents = await factory.getEvents.PoolCreated();
    expect(createEvents).to.have.lengthOf(1);
    expect(createEvents[0].args.pool).to.match(/^0x[a-fA-F0-9]{40}$/);
    expect(createEvents[0].args.token0).to.equal(tokenB);
    expect(createEvents[0].args.token1).to.equal(tokenA);
    expect(createEvents[0].args.tickLower).to.equal(1);
    expect(createEvents[0].args.tickUpper).to.equal(100000);
    expect(createEvents[0].args.fee).to.equal(3000);
  });
});

in this test, we call createPool method, and then pass getEvents to get the event to determine whether the creation was successful.

As we mentioned above, the function return value is only truly created after the transaction is packed into the block, so in the Test we pass waitForTransactionReceipt to wait for the transaction to be packaged into the block. You can also pass factory.simulate.createPool method to do a simulated transaction, used to verify the return value of the function:

// simulate for test return address
const poolAddress = await factory.simulate.createPool([
  tokenA,
  tokenB,
  1,
  100000,
  3000,
]);
expect(poolAddress.result).to.match(/^0x[a-fA-F0-9]{40}$/);
expect(poolAddress.result).to.equal(createEvents[0].args.pool);

add another test example of abnormal state:

it("createPool with same token", async function () {
  const { factory } = await loadFixture(deployFixture);
  const tokenA: `0x${string}` = "0xEcd0D12E21805803f70de03B72B1C162dB0898d9";
  const tokenB: `0x${string}` = "0xEcd0D12E21805803f70de03B72B1C162dB0898d9";
  await expect(
    factory.write.createPool([tokenA, tokenB, 1, 100000, 3000])
  ).to.be.rejectedWith("IDENTICAL_ADDRESSES");

  await expect(factory.read.getPool([tokenA, tokenB, 3])).to.be.rejectedWith(
    "IDENTICAL_ADDRESSES"
  );
});

the complete single test code is in demo-contract/test/wtfswap/Factory.ts in the actual project, your single test should cover all logical branches to ensure the security of the contract.