[Ethereum] Contract code size (and how to work around it?)

bytecodeerc-20solidity

I'm writing some rather substantial Solidity smart-contracts, and believe I'm hitting the EIP170 24k bytecode size limit. I've already

(a) factored my code into libraries

(b) today split my contract into two parts.

Nothing seems to be helping to get under the limit. Heck, splitting into two contracts -increased- -severely- the code of one of the two resulting contracts — much bigger than the original all-in-one contract.

Are there tools to help figure out where the code-bloat is coming from? Other methods for splitting-up in order to reduce size?

Best Answer

Most probably the bytecode bloat comes from the new statements in your code. They're often the trouble maker because they include the code of the contract to be instantiated. You can create contract factories which you can deploy in front. This way you can reduce the bytecode size of your main contract.

E.g.

contract X {}

contract XFactory {
    function createX() returns (X) {
        return new X();
    }
}

contract Main {
    XFactory xFactory;
    ...
    Main(XFactory _xFactory) {
        xFactory = _xFactory;
    }
    ...
    function someMethod() {
        X x = xFactory.create();
    }
    ...
}

Related Solutions

[Ethereum] Best practices to solve the problem of a contract that is too large

For Q1: Assuming your contract is too large because you have complex data structures in it and therefore complex business logic to manipulate them, my approach has been to review the data model and consider some of these data structures to be contract themselves. For instance, your main contract holds a mapping of structure that contains array. If it is functionally relevant consider converting the structure into a contract and defining some business logic into this contract. In other words, try defining your object model by creating different contract for elements that have independent or different life cycles.

Q2: Rob already answered to this. I will just add that mapping and array automatic getter do not provide a length function. And mapping cannot be iterated over if you do not have already the list of keys.

Q3: here it depends if you can break your business logic to manipulate your data structure independently. From a gas perspective the more straightforward the VM process is the lower the gas will be. Also, with complex data structure one can assume searching in arrays, mapping, sorting and remapping that have a tendency of being loop intensive. So structure your internal data so you have a way to speed up the algorithms. For instance, i needed a sorted list of dates, i built it in a way that the inserting function keep it sorted. Another example is to delegate to the external caller more work to do, ie more separate transactions when possible. Update attributes of a contract in different calls versus one single call will all values.

Good luck and share your findings

Solidity Inheritance – Issues with Multiple Contracts and Inheritance in Solidity

At compilation all contracts are combined together to produce one bytecode so inheritance will not be very helpful to decrease contract size.

From the error message the problem seems to be not enough gas and it appears you are using the default gas 6.7M gas. For reference at this moment mainnet has a block gas limit above 12M gas.

A temporary solution is increasing the block gas limit.

For truffle edit the network configuration and add gas parameter.

networks: {
  development: {
    host: "127.0.0.1",
    port: 8545,
    network_id: "*",
    websockets: true,
    gas: 12000000          // <--- Increased block gas limit
  },

For ganache-cli pass requested gas to -l parameter:
```
  ganache-cli -l 12000000
```

An alternative to have separate contract is using libraries to separate functionality. It requires more planning to separate into libraries and adjusting the migrations scripts to deploy and link libraries into main contracts.

pragma solidity >=0.4.0 <0.8.0;
pragma experimental ABIEncoderV2;

library PizzaLib {
    struct Pizza {
        uint256 ingredients;
    }

    function mix(Pizza calldata pizza, uint256 ingredients) external pure returns (Pizza memory) {
        Pizza memory p = pizza;
        p.ingredients = ingredients;
        return p;
    }
}

contract PizzaShop {
    using PizzaLib for PizzaLib.Pizza;
    
    function foo() public pure returns (PizzaLib.Pizza memory) {
        PizzaLib.Pizza memory pizza;
        pizza = pizza.mix(23);
        return pizza;
    }
}

For example migrations will look like

module.exports = async function(deployer, network, accounts) {
  await deployer.deploy(PizzaLib);
  await deployer.link(PizzaLib, PizzaShop);
  await deployer.deploy(PizzaShop);
}

Best Answer

Related Solutions

[Ethereum] Best practices to solve the problem of a contract that is too large

Solidity Inheritance – Issues with Multiple Contracts and Inheritance in Solidity

Related Topic