Removing Contract Size Limit

[maxsam4]

Abstract
A contract size limit of 24kb was introduced by EIP #170 . To solve the following problem problem: "when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity". I think we can solve this problem while still allowing infinite contract size.

Motivation
Complex dApps require complex smart contracts. I have seen a lot of dApp developers struggle with this and a lot of alternative solutions are being used like using delegate calls. Delegate calls reduce code readability while developing and while verifying source code on tools like etherscan. They also introduce another attack surface and added complexity.

Specification

1. The ethereum account array in state trie saves another element codeSize apart from existing 4: [nonce,balance,storageRoot,codeHash]
2. Whenever a new contract is deployed, its size is stored in codeSize of the account object.
3. If a contract is destructed, the codeSize should also be reset.
4. opcodes like CALL, DELEGATECALL, CALLCODE etc should charge additional X(3?) gas per extra word if the contract code size is greater than 24kb.

Rationale
The only reason why contract size was limited was to prevent people from exploiting the fixed costs. We can overcome this by making the costs variable. The codeSize element will help in calculating call cost before reading the whole contract and eventually throwing OOG. Merkle proofs will also be generated at fixed cost as we won't have to load the huge contracts from disk first. The codeSize should be enough.

Backwards Compatibility
We don't necessarily need to refactor the existing account arrays as all the existing accounts have less than 24kb of code so no extra cost has to be charged from calls being sent to them. We can assume X = 0 if it's not available.
This will mean that there are no backward compatibility issues.

This is just an early discussion Issue. I will create a properly formatted draft with specifications after getting some more feedback from the community.

References
#170
#659
https://github.com/ethereum/wiki/wiki/Patricia-Tree#tries-in-ethereum

[bonedaddy]

If your contract is 24KB or larger, your contract architecture needs a seriously big redesign

[maxsam4]

If your contract is 24KB or larger, your contract architecture needs a seriously big redesign

Thank you for your feedback. That's a debatable point but I get why you think so.

Contract size increases due to multiple factors that don't really add to the complexity of the code. For example,

1. Reason strings take a hell lot of space.
2. Getter functions for ease of use of front-end devs or normal users take a lot of space.
3. Solidity 0.5.0 produces larger bytecode than solidity 0.4.24 for the same contract with required explicit definitions.
   etc

Obviously, the contract size also increases when you add functionality.

[nervehammer]

i agree with @maxsam4, we at NexusMutual have complex logic that are split into multiple smaller contract. Have a look here: https://github.com/somish/NexusMutual/tree/token/contracts

[0xKiwi]

I would support at least a minor increase in the smart contract max size, sure you can usually split logic into several contracts but with reason strings and developers learning more about options for Smart Contract design, I believe an increase (even if minor) is due.

[mudgen]

As a note, the contract size limit can be removed by implementing ERC1538.

[maxsam4]

As a note, the contract size limit can be removed by implementing ERC1538.

Yep, that is one way to do it but it's not optimal because of limitations like:

1. It adds extra unnecessary code.
2. Adds another attack vector.
3. Makes intra contract calls more expensive.
4. Makes it harder for non tech-savvy users to interact with it. Like it or not but most people can barely use the read/write feature in etherscan, they can't load a custom ABI and make web3 calls.
5. Makes it harder for beginners to verify the code and hence reduces trust.

I am still collecting feedback on this. I think there are 3 basic ways that this proposal can go:

1. Ethereum is not meant for complex ecosystems, smart contracts must be less than 24kb always. Alternative solutions that currently work like ERC1538 can still be used.
2. A variant of this proposal is accepted and when combined with the scalability of serenity, ethereum will be able to support really complex dApps.
3. Changes are made into EVM to support pagination or maybe keeping the EVM as it is and adding pagination to high-level languages like solidity. i.e. whenever solidity will see the contract size go above ~20kb, it will split it into two contracts and connect them through proxies. the end user will never know the difference.

[amiromayer]

👍🏻 Agree with @maxsam4. Would also support the increase in contract size limit.

As a note, the contract size limit can be removed by implementing ERC1538.

Yep, that is one way to do it but it's not optimal because of limitations like:

1. It adds extra unnecessary code.
2. Adds another attack vector.
3. Makes intra contract calls more expensive.
4. Makes it harder for non tech-savvy users to interact with it. Like it or not but most people can barely use the read/write feature in etherscan, they can't load a custom ABI and make web3 calls.
5. Makes it harder for beginners to verify the code and hence reduces trust.

I am still collecting feedback on this. I think there are 3 basic ways that this proposal can go:

1. Ethereum is not meant for complex ecosystems, smart contracts must be less than 24kb always. Alternative solutions that currently work like ERC1538 can still be used.
2. A variant of this proposal is accepted and when combined with the scalability of serenity, ethereum will be able to support really complex dApps.
3. Changes are made into EVM to support pagination or maybe keeping the EVM as it is and adding pagination to high-level languages like solidity. i.e. whenever solidity will see the contract size go above ~20kb, it will split it into two contracts and connect them through proxies. the end user will never know the difference.

[ayushgupta0610]

I agree with @maxsam4 , even after making use of library contracts, proxy patterns, breaking huge contracts to multiple smaller contracts, there still comes a point which requires the smart contracts' byte code to be extended beyond a certain limit. It's just not developer-friendly to restrict the developers to develop smart contracts to limited complexity.

[jpmonettas]

I also agree with the importance of fixing the contract size limit issue.
Auditability and trust are very important for this systems and a big part of that comes from the languages letting you express your logic as clean and straight forward as possible. It is much harder
to do it if you also need to consider this limitation.
Don't know if the limitation should be fixed at Ethereum level or compilers one.

[chris-shyft]

I'm hitting the same limit. Libraries aren't enough.. I don't care about high(er) deploy costs at whatever level, for some larger contracts that need to deal with asset transfers, you need the transaction costs to be low and deploy cost means very little at scale.

Meanwhile, cross-links (contracts with state to member contracts via interfaces) are useful as well. But they still run into the same issue as mentioned above.

Increasing it to one of the earlier suggestions of 2^15 would be almost a substantial amount more headroom than currently.

[maxsam4]

Thanks everyone for the feedback! I think I have got enough feedback to justify moving forward with this Idea. I will try to draft a proper proposal/document this weekend and will collect feedback on it via different mediums.

[maxsam4]

I have summed up most of my thoughts regarding this in a small write up available at https://ethereum-magicians.org/t/removing-or-increasing-the-contract-size-limit/3045

Please have a look. All feedback is welcome.

[0zAND1z]

@gcolvin & @chriseth , could you please take a look into this & guide this thread ahead?

After multiple audits & optimizations, a lot of contract developers seems to be sharing a common observation. We would love to have your inputs on this.

Cheers.

[zmitton]

@maxsam4 over on Ethereum Classic we don't yet have a size limit and are debating adding EIP-170. This is a viable alternative, I have a question. Why do we need to cache the size data into the account tuple. Can't we do it without changing the account format? Cant we just have the EVM load a contract's bytecode and then determine the gas cost and charge it at that point?