encourage use of instances over separate wasms

[graydon]

We've heard feedback that users seem to be uploading multiple wasms (and paying the comparatively high storage costs for them) in cases where it might make more sense (and be much cheaper) to upload a single wasm and create multiple instances of it (with varying parameters / instance storage).

Things to do here:

• make a list of actual contract-families where this seems to be a problem
• possibly improve docs to clarify the cost savings benefit of using multiple instances
• possibly investigate open-zeppelin compile-time gating of contract features
• possibly make a catalogue of reusable contract code entries that are already on-chain
• possibly continue working on build reproducibility in case that's a main cause
• possibly find other causes of this pattern (NFTs?)

Also open to other explanations! Please comment if you have ideas.

[ElliotFriend]

Haven't seen this in the wild, but also haven't gone looking for it. I've long thought that if people use the OpenZeppelin wizard to create a token/NFT/etc. contract, they'll be compiling a completely unique Wasm executable, because the wizard hard-codes the token name, symbol, etc. into __constructor() function. If they were passed as arguments to the constructor, then there would be some handful of executables on-chain, representing every possible combination of OZ features from the wizard. (That line of thinking assumes they upload without further customizations.)

Just been a thought running through my mind. Don't know that anyone would actually upload the thing as-is, without first customizing it somehow.

[leighmcculloch]

open-zeppelin

Folks using the Open Zeppelin wizard and writing almost identical contracts with just the hardcoded strings being different will result in unique wasm file with the only difference being in the data section, and maybe a little in the code section if the lengths of teh strings are different. For example, this diff is of two wizard generated tokens that differ in their hardcoded values. Displayed is the length change in the code section and different hardcoded values in the data section:

@@ -45,12 +45,12 @@
     local.tee 0
     global.set 0
     i32.const 1048576
-    i32.const 7
+    i32.const 8
     call 18
     local.set 1
     local.get 0
-    i32.const 1048583
-    i32.const 3
+    i32.const 1048584
+    i32.const 4
     call 18
     i64.store offset=24
     local.get 0
@@ -1710,4 +1710,4 @@
   (export "_" (func 48))
   (export "__data_end" (global 1))
   (export "__heap_base" (global 2))
-  (data (;0;) (i32.const 1048576) "MyTokenMTK\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ownerspender(\00\10\00\05\00\00\00-\00\10\00\07\00\00\00amountlive_until_ledger\00D\00\10\00\06\00\00\00J\00\10\00\11\00\00\00TotalSupplyBalanceAllowancedecimalsnamesymbol\00\00\00\87\00\10\00\08\00\00\00\8f\00\10\00\04\00\00\00\93\00\10\00\06\00\00\00"))
+  (data (;0;) (i32.const 1048576) "MyToken1MTK1\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00ownerspender(\00\10\00\05\00\00\00-\00\10\00\07\00\00\00amountlive_until_ledger\00D\00\10\00\06\00\00\00J\00\10\00\11\00\00\00TotalSupplyBalanceAllowancedecimalsnamesymbol\00\00\00\87\00\10\00\08\00\00\00\8f\00\10\00\04\00\00\00\93\00\10\00\06\00\00\00"))