What is the max data and program complexity one smart-contract can support

Question

I want to make a smart-contract for P2P trading. I am wandering if I have to create separate contracts for each bid and agreement between two entities, or I can simply create a single contract that contains all the bids and the agreements between users?

Having only one contract will facilitate the access to it, as I will have to mange only one address, however, if I will have multiple contract, how I can manage them? especially if I will use oracle to allow external devices to provide the contracts with some external data.

Thanks.

Answer 1

What I normally use in cases like these is a "master" contract whose owner is the platform and deploys a separate contract for each "detail" contract. In your case, my suggestion is to have each bid in a separate contract, where you can store bidders address and even set a owner which is not the platform, and store the address of each bid contract in a mapping in the master contract.

Using such a scheme would allow the platform to "control" bids and bidders to deal with the bids without going through the platform. In my experience it also keep code easier to write and maintain.

Answer 2

There is no upper limit on complexity or data storage but there are constraints to be aware of.

The main constraint is maximum transaction gas cost a.k.a. block gasLimit, which is a variable network property voted on by the miners. This is an upper bound on the computational complexity of a single atomic transaction. Implicitly, this is a limit on the maximum size of a contract that can be deployed in one gulp.

It can be useful to break up large contracts into systems of smaller contracts that interact to ensure no single component is too large to deploy. As Marco pointed out, you can (and should) strictly control access to each component.

While there is no upper limit on the amount of data that is stored in a contract's state, there are two factors to keep in your top-of-mind.

1. Avoid iterative processes. You need to ensure that gas cost for all interactions is scale-invariant. See here: Are there well-solved and simple storage patterns for Solidity? and here: https://blog.b9lab.com/getting-loopy-with-solidity-1d51794622ad
2. Remember that the system is financially constrained. The dataset can be as large as you and your users are willing to finance. So, while it's theoretically possible to fill mappings and arrays with massive amounts of data, affordability tells another story.

Also worth keeping in mind is the idea of amortization of work. I believe that phrase was first put forward by Nick Johnson (reference in the articles linked above). Basically, there is no limit to the complexity of a state transition if it is modeled as multiple smaller atomic transactions, but each atomic transaction must always complete within the gas limit.

Hope it helps.