In this article, I am going to raise a point about deployment of complicated smart contracts systems.

It is a rather common situation when one needs to deploy two contracts, say A and B, that “know” each other. This means that contract A keeps the address of contract B and vice versa.

There is one common solution to this problem:

Deploy contract A, which includes setter function. Deploy contract B with the address of contract A passed as constructor parameter. Set the address of contract B in contract A using a setter function.

The drawbacks of this way are obvious:

Extra payment for setter function at deploy of contract A. “Garbage” setter function left in ABI of contract A. Modifiers for all functions that check setter function to be previously called.

The problem can be bypassed in case we know the address of contract B at the moment of contract A deployment. Fortunately, the address of to-be-deployed contract can be precomputed in the deploy script: it depends just on deployer’s address and transaction nonce. Also, it requires ethereumjs-util package to conduct all the computations.

Here is the simple example:

Thus, we moved the difficulty of the system to the deploy script. In the current implementation, the contract deployment is a bit more complicated. However, this solution simplifies contracts code, makes deploy cheaper, and increase code readability.

One important thing: do not forget to ensure that deployerAddress is the real address of deployment!