Learn Solidity: The Factory Pattern

How to use the factory pattern in your smart contracts

Photo by Ant Rozetsky on Unsplash.

Welcome to another installment of the Learn Solidity series. In the previous article, we discussed how to create a smart contract from within another smart contract. Today, we will take a look at a typical use case for this scenario.

What Is the Factory Pattern?

The idea of the factory pattern is to have a contract (the factory) that will carry the mission of creating other contracts. The main motivation for this pattern in class-based programming comes from the single-responsibility principle (a class does not need to know how to create instances of other classes), and this pattern provides an abstraction for the constructor.

Photo from Wikipedia.

Why Use the Factory Pattern in Solidity?

In Solidity, you might want to use the factory pattern for one of the following reasons:

• If you want to create multiple instances of the same contract and you’re looking for a way to keep track of them and make their management easier.

• Save gas on deployment: You can deploy only the factory and use it later to deploy the other contracts.
• Improve contract security (see this article).

How to Interact With Deployed Smart Contracts

Before diving into the details of how to implement the factory pattern, I would like to make things clear about the way we can interact with a deployed smart contract. The factory pattern is about creating child contracts and we might want to call some of their functions for better management of these contracts.

There are two things needed when we want to call a deployed smart contract:

1. The ABI of the contract (provides info about functions signatures). If the contract is in the same project. you can just import it using the import keyword.
2. The address of the deployed contract.

Let’s have an example:

In Remix, start by deploying contract B, then copy its address and give it to the constructor of A when deploying it. You can now call the callHello() function and you will get the result of the sayHello() function of contract B.

Normal Factory Pattern

In this pattern, we create a factory contract with a function that handles the creation of child contracts and we might also add other functions for efficient management of these contracts (e.g. looking for a specific contract or disabling a contract). Inside the create function, we use the new keyword to deploy the child contract.

Clone Factory Pattern

The problem with the previous pattern is that it wastes lots of gas since all child contracts will have the same logic and we redeploy almost the same contract each time — same code but different context. We need a way to deploy only one child contract with all the functions and make all other child contracts act as proxies that delegate calls to the first child contract we created and let functions execute with the context of the proxy contracts.

Photo by the author.

Fortunately, there is the EIP-1167 specification that defines how to implement a proxy contract cheaply. This proxy will forward all calls and 100% of the gas to the implementation contract and then relay the return value back to the caller. The bytecode of the proxy contract according to the specification is
363d3d373d3d3d363d73bebebebebebebebebebebebebebebebebebebebe5af43d82803e903d91602b57fd5bf3. The bytes at indices 10-29 (inclusive) are replaced with the 20-byte address of the master functionality contract (the contract to which we will delegate the calls).

The whole magic of the proxy contract is done using delegatecall. You can get an idea of how it works by reading this article.

Let’s see now how to make this work. First, you need to grab the implementation of this specification, which you can find on GitHub. Copy-paste the code of CloneFactory in your project.

The code we’re going to use this time is as follows:

This time, we used the createClone function from the GitHub repository to create child contracts instead of the new keyword.

You can deploy the contracts by creating a new migration file in Truffle that looks like this:

To test if the code works, I created a test file that you can try on your own to make sure that everything is working as expected:

Conclusion

That’s it for this article. Stay tuned for more on smart contract development!