Comments (6)
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.
from beaker.
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
from beaker.
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?
from beaker.
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.
from beaker.
Ok great I'll report on the progress on #59 as we test the gas settings.
from beaker.
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.
from beaker.
Related Issues (20)
- Make Beaker js an npm package
- Add support for querying contract state and executing arbitrary contract messages HOT 5
- beaker cli broken after building osmosis binary HOT 8
- feat: allow to execute messages by code id instead of contract name HOT 1
- Optimize pipeline
- getState()?.counter.addresses.default missing "default" attribute when deploy the contract with --label HOT 6
- Instantiate should not error when there is no store code proposal HOT 1
- bake osmojs into the console
- Can't deploy to testnet with Beaker HOT 2
- Can't open beaker console after ts-gen HOT 4
- Deploying Contracts on Sei rather than Osmosis HOT 7
- run cosmos-sdk tx and query from Task script
- cargo install fails HOT 3
- h2 protocol error: http2 error: connection error detected: frame with invalid size HOT 2
- Can't install Beaker HOT 8
- do not prefix with artifacts if absolute path given
- Add top level CI support
- Speed up beaker wasm build on Mac Silicon HOT 1
- Update ts codegen tooling HOT 3
- Bail on external command line error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from beaker.