Contract exceeds block gas limit

Question

I have a fairly complex contract that inherits from a bunch of other contracts, like the OpenZeppelin ERC20 libs and Oraclize libs.

When I go to deploy it onto testnet in Remix or Mist, it says that the gas required is 6.3 million, which exceeds the limit. Is there a way that I can deploy it piecemeal, or do I simply have to make the contract less complex?

If I don't use Oraclize, gas required goes down to 4 million and I can deploy the contact successfully.

Answer 1

Here's a tutorial and general approach:

https://dappsforbeginners.wordpress.com/tutorials/interactions-between-contracts/

You split the contract into several contracts, and you can create references to "parent" contracts, such as:

contract referencedContract {   
  function fn() {}
}

contract referencingContract{

  // create reference to contract
  referencedContract m = referencedContract(referencedContractAddress);

  // call referenced contract method
  m.fn();
}

Answer 2

You can sometimes divide code into multiple contracts by using libraries. Theoretically, you could divide a contract of any size into libraries with sufficient work.

Are there any structs you use in the contract? You can possibly make them far easier to use and consume much less space with a library and a using for declaration.

Even if libraries won't quite work, sometimes it's possible to split a dapp into several contracts that work together. (The ENS system, for example, uses multiple contracts in this fashion, let alone all the Deeds and resolvers that users add.)

Answer 3

The mainnet gas limit is 6.7M at the moment, which is actually higher than what your contract uses to deploy, so even in its current state it would be deployable there. When testing on http://dapps.oraclize.it/browser-solidity/ which is Oraclize's browser-solidity/Remix fork, with an included Oraclize bridge module, you can actually test your contract right on the JVM, no need for a testnet, in which you can change the block gas limit to whatever you desire.

However, a better solution is of course to go with a modular design of your contract, where different parts, such as the storage and logic, are in separate contracts, which connect to each other via a central resolver. This modularity also helps with integrating some potential update features. In addition to separating the above, you can leverage Oraclize's api library as well, which will end up being deployed separately from your main contract, but will be linked and do delegate calls to the library: https://github.com/oraclize/ethereum-api/tree/master/lib-experimental

Note, it is considered experimental, but we are using it in some showcase demos of ours, successfully and without issues so far.