[Ethereum] How many arguments can Solidity take

Solidity docs say that sha256 (and sha3, ripemd160) arguments are tightly packed:

“tightly packed” means that the arguments are concatenated without padding. This means that the following are all identical:

sha3("ab", "c")

sha3("abc")

sha3(0x616263)

sha3(6382179)

sha3(97, 98, 99)

Using the question's example of a = sha256(uint b, string c, bool d),

• if we assign some values like b is 31415, c is "abc", and d is false,

• then a would equal sha256(31415, 6382179, 0), which is same as sha256(0x7ab761626300).

For completeness, the docs mention that:

If padding is needed, explicit type conversions can be used: sha3(“x00x12”) is the same as sha3(uint16(0x12)).

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.