[Research] Gas settings in mainnet
daniel-farina opened this issue · 6 comments
For some more context: I believe I was concerned about on mainnet you can't easily submit txs that take > 25M gas.
How much gas do contract uploads / proposals take? If more than this, we need to start asking validators / nodes to increase this config param
I think let's look at biggest code stored on terra / juno and try submitting that on our testnet, monitor gas consumption? That should give us good hints. The gas consumption calc logic is consistent across the chains (local/testnet/mainnet), am I correct?
I think let's look at biggest code stored on terra / juno and try submitting that on our testnet, monitor gas consumption? That should give us good hints. The gas consumption calc logic is consistent across the chains (local/testnet/mainnet), am I correct?
I can give some insight on this. On Terra, the max_contract_size parameter was set to 614400 bytes. We were constantly bumping up against this and needed to do a bunch of optimizations and workarounds to keep one of our contracts below this size. Here's an example of a MsgStoreCode where we upload a contract that is 612Kb.
The gas used was 7,437,249. At the standard Terra gas price of 0.15uusd this should have cost $1.11 if unused gas would have been refunded (any insight on if gas refunds are being worked on?). This feels like an okay price for uploading a contract, but I would say that the cost of uploading contracts is not very important since it won't be done very often. Instead it makes more sense to look at how much gas a typical CosmWasm contract execution takes. This of course varies a lot depending on how complex the execution is, but as an example here is a transaction where someone is exiting an Apollo vault. This used 3,994,206 gas and would have cost $0.59, which I personally feel is somewhat high. What I've discovered is that most code in CosmWasm use almost no gas at all, and that almost all the gas is used by doing SmartQueries and returning CosmosMsgs from ExecuteMsg handlers. @ethanfrey has told me that it needs to be this way because loading those called contracts into memory takes time for the validator's and thus if this were cheap to do the block time could increase (Ethan: please correct me if I misremember your explanation). He suggested a workaround for this would be to flag certain contracts as always staying in the validators' memory. This seems like it could be a viable solution on Osmosis since it is permissioned and likely won't have many contracts.
The osmosis gas cost is about 100x cheaper today then were Terra was at, so in terms of gas USD costs I don't think we need to be super worried.
On Osmosis, the current max contract size is 800kB as far as I understand: https://github.com/CosmWasm/wasmd/blob/main/x/wasm/types/validation.go#L11-L12
Looks like for contract uploads we maybe don't need to be worried? (Frey mentioned at one point that theres is a notably gas overhead for the governance proposals over a normal upload. Can someone post once they try that) We run into 25M limits at the moment, which seems fine.
There is no unused gas refund work going on, its blocked on subsequent SDK releases right now.
Those gas counts do look excessive for exiting an apollo vault, we should look into we can tune down that gas amount. Or get those contracts in a cache, especially as in Osmosis we have bounded amounts of wasm code. Right now, 4M gas / contract call would lead to Osmosis blocks getting filled rather quickly.
Ok great I'll report on the progress on #59 as we test the gas settings.
Those gas counts do look excessive for exiting an apollo vault, we should look into we can tune down that gas amount. Or get those contracts in a cache, especially as in Osmosis we have bounded amounts of wasm code. Right now, 4M gas / contract call would lead to Osmosis blocks getting filled rather quickly.
Yeah as mentioned I think almost all of the gas is due to SmartQuery and returning CosmosMsgs from ExecuteMsg handlers. This can be optimized somewhat, but often leads to more complex code. Pinning/caching seems like the best option to me.