How many variables/ rows can contracts handle?

Question

From the article: Are there well-solved and simple storage patterns for Solidity?

Ignoring costs, does anyone know how many variables/rows a solidity contract using each of the types can handle? Or is this limited by transaction size more than anything?

More specifically, when will my contract crap out?

  struct DocumentStruct{
bytes32 name;
uint value;
}

 mapping(bytes32 => DocumentStruct) public documentStructs;

 function StoreDocument(bytes32 key, bytes32 name, uint value) returns (bool success) {
  documentStructs[key].name  = name;
 documentStructs[key].value = value;
 return true;
}

Answer 1

Scale-variant solutions, meaning processes with computational demands that increase with the size of the table increases are (generally speaking) bad form for Solidity Contracts since the cost of functions will assuredly increase until either a) the cost of using the contract is uneconomical or b) the block gasLimit is exceeded. Condition b) renders the function impossible to execute at any price.

Each of the patterns is designed to be scale-invariant. The cost in gas will be consistent at any scale. As Thomas pointed out, max rows is a really large number. It would represent a really large gas investment.

You can run any of the examples, or your own implementation of the patterns, test (e.g. with Remix) and proceed confident that the gas and performance won't change as the tables grow in size. In other words, you can (and should) know your cost.

The cost wouldn't necessarily be borne by the contract owner. When contracts are designed to align gas expenditures with user benefits, we can imagine this cost allocated fairly between users creating the data set.

While the Solidity contract examples are designed for efficient and consistently modest fees, two factors affect the future price of updates. First, market forces affect the price of ETH and therefore gas. Second, future protocol changes can alter the costs of low-level operations from which total gas is calculated.

This second point bears mentioning. Even though the code maintains equal sized operations and control flows at any scale, current gas estimates are, of course, calculated by Ethereum's "price list" for the op codes. Periodic adjustments to the price list are conceivable (protocol changes). Future changes to the price list and the future value of Eth can't be forecast with any precision in my opinion.

As a contract designer, the best posture in my opinion is to aim for a consistent and low overall cost, since this assures that the functions are executable at any scale.

Hope it helps.

Answer 2

The answer above is technically incorrect. Your contract will be able to store no more than 2^256-1 entries, but that number is so large it's not possible to get anywhere near full.

The more important point is the cost associated with storing data on the blockchain. I read somewhere that storing as little as a megabyte could cost many thousands of dollars, and that was before the price of ether spiked.

You should definitely understand how much it will cost before you plan on storing too much data on chain. What people have been doing instead is storing the data in IPFS and storing only the hash of that data on chain.

Answer 3

Actually your question is not so clearly. Do you mean is there any limitation of contract variable's size?

The contract above you write is legal and you needn't to worry about the variable documentStructs will overflow.

Map type is a dynamic type in solidity, each element in map will be assigned a unique storage slot(address calculated by hash function) to store. storage size is unlimited. Therefore, conceptually speaking a map will never overflow.

Here is a link, in it contract storage organization is described clearly. Hope it can help you.

Answer 4

Ignoring costs, does anyone know how many variables/rows a solidity contract using each of the types can handle?

This doesn't apply specifically to adding entries to your mapping, but in general one thing to bare in mind is the size of the stack.

Adding local variables to a given function would likely result in a "Stack too deep" error, as per this previous thread:

Error while compiling: Stack too deep

It used to be that 17 local variables (invariant of type, I think) was the limit.