Only need to store the hash of the init code
We can just store pre-computed address at that point. Doesn’t make sense to compute it on the fly.
In an eth2 context, that sounds like a big problem if true!
I guess contracts can be re-architectured to overcome this problem. However, In most calls, you’ll need to load at least 3 pages (main dispatcher, utility function page, main function page). That requires 3 random read i/o blocks. If it were a monolithic single contract, It would have required only 1 block read (Most SSD have block size > 512 KB). This means it will be more taxing for the full nodes to process paged contracts.
I agree that for stateless clients, it’s better to have paged contracts if they are architectured properly. I don’t see many people using stateless clients though.
That being said, I don’t see this as a big problem for even stateless clients. If anyone was going to dos stateless clients, they can just create 24KB contracts and call an empty function on each of them. As the cost of CALL is going to increase as the size of contract increase over 24KB, It won’t make a difference if the griefer uses 24KB contracts or 32KB.
The effect of average daily use will be minimal and worth the advantages IMO.