I am still wrangling with the data on the stateless client, to complete my post, but I would propose (in the 4th version of State fees/rent proposal) to only introduce stateless clients approach for contract storage items. I am currently missing data on whether size of the block proofs (witnesses) for contract storage eventually overtook the block proof for accounts and for the code size, because at the block 5.4m those 3 components were roughly on par. That is it to say, that byte codes played significant part in the block proof, and increasing contract sizes can push it up even further.
Even if we were to go with the pagination approach, we need still look at the compilers to try to optimise the code so that the code of specific functions are partitioned well (i.e. usual function calls do not end up touching all the pages).
In general, I would approach this proposal with caution, and also in the context of other EIPs that propose to change EVM, most notable EIP-615. I would definitely welcome more research.
For example, it was noted that the code of the contract is inflated by the PUSHx opcodes storing data inline in the code. Perhaps, the solution to this is to use DATA segment approach that has been introduced into EIP-615?
Another point - some of the desire to put lots of code into a single contract stems from the fact that this code wishes to access the same storage, without calling wrapper contracts. Currently, it is very appealing, because reading storage (SLOAD) cots 200 gas, and any call to a wrapper adds an extra cost of 700 gas to that, so it ends up being 900. But the cost of SLOAD is likely to be increased 4x or 5x, because it is overpriced, so the relative win from co-locating the storage would decrease.
For example, it was noted that the code of the contract is inflated by the PUSHx opcodes storing data inline in the code. Perhaps, the solution to this is to use DATA segment approach that has been introduced into EIP-615?
As I understand, the DATA will still be part of the code and require to be fetched so it shouldn’t really affect the total code size by much. It will reduce the verification time though.
reading storage (SLOAD) cots 200 gas, and any call to a wrapper adds an extra cost of 700 gas to that, so it ends up being 900
Actual overhead is around 1500-2500 because we can’t directly access the storage of other contracts. We need to call a function in the external contract that will return the data we need (Applies to delegatecalls as well). The copying of data also ads to the cost. even if SLOAD costs are increased to 1000, it will still be 50% cheaper.
In general, I would approach this proposal with caution, and also in the context of other EIPs that propose to change EVM, most notable EIP-615. I would definitely welcome more research.
IELE provides just the natural numbers, but I think it has fused mod operators like the EVM to work in any fixed modulus. Since the hardware supports fixed-width scalars and vectors of power-of-two sizes it makes sense to abstract that model, but EIP-616 is on hold as we wait for the Wasm spec for wide SIMD. eWasm will get SIMD by default when Wasm does; natural numbers could be coded as HLL libraries.
Part of the problem is that the higher-level concept corresponding to contracts with delegatecall isn’t the subroutine but the coroutine. So you can’t directly translate a program consisting of subroutines into a collection of contracts, even in languages like Go and Python that support coroutines. But subroutines are a subset of coroutines, so it should be doable.
Consensys Diligence recently made a suggestion or recommendation that Codedefi’s implementation of ERC1400 use the Diamond Standard to handle the problem of maximum contract size limit.
Diamonds are ideal for contract systems like tokens that deal with a lot of state and code, because they help you organize your code around contract state without running into the max contract size.
Another possibility is to look at options to reduce the size of the byte code.
This could be done by using more opcodes. Not using all possible 256 opcodes consumes more space. For instance, new opcodes push-all-zeros and push-all-ones would reduce (future) byte code size.
Additionally, enhancing the compiler optimisation could consume less space.
Lastly, changes to the Solidity language, e.g. allowing constant arrays, faster calling techniques, could consume less space.