Original Post: Commonwealth
I propose pinning Mars protocol contract binary codes via an on-chain PinCodesProposal.
Pinning a smart contract’s code means the node software will always keep it in the cache. This increases memory usage but reduces the gas cost for executing or querying the contract.
In the case of Mars Red Bank, which consists of only 5 contracts that sum up to less than 2 MB, the increase in memory usage is negligible. However, considering Red Bank will likely become the most frequently used contracts on Osmosis, a very big amount of gas can potentially saved. I suspect this will also reduce the load on CPU and disk for node operators.
Assuming that this has to happen for every contract uploaded, are the Red Bank contracts finalised or are they likely to be patched in the coming weeks as other parts of Mars roll out?
There is expected to be a minor upgrade soon (will be discussed in Mars forum; code changes are tracked by this PR). After that likely no more upgrade in the short term.
Indeed, each time an upgrade is deployed, we need to unpin the old code and pin the new code.
So every upgrade would require 1 or 2 governance proposals?
The impact on the validators in terms of hardware does not seem so special, I am more “afraid” on the load in governance. Especially if we want to do this for more than 1 contract.
Besides the load of proposals we already have we would introduce a new category which might require frequent governance proposals.
To give an insight in the advantages; how big in gas reduction are we talking about?
And is it beneficial for users? Since we are still able to send 0-fee txs on chain, effectively making the cost of a tx 0.
Or is the concern more the amount of transactions which can fit into a block?
Makes sense to go for it after the upgrade then. Longer term, would it be worth working with Confio to change the whitelisting on upload feature to be more of a “CosmWasm Curation” whitelist address?
@Leonoor’s Cryptoman I can’t seem to reply to your comment (Commonwealth doesn’t allow nesting too many layers of replies)
the load in governance
We can modify the wasm module’s code, adding a “combo proposal” that does both code upload + pinning in one go. Dev has mentioned he wants to do this.
how big in gas reduction are we talking about?
No data on this; I have not done a benchmark. However I think the marketplace contracts are Stargaze are pinned; maybe they have insights on this.
Since we are still able to send 0-fee txs on chain
This is only true for txs that consume less than 1M gas. For txs that consume equal or more than 1M gas, Osmosis has implemented a separate fee tier which defaults to 0.0025 uosmo/gas.
The devs have also expressed interests in making an in-protocol minimum gas price (in contrary to being configured by individual node operators.)
Thanks for the reply @larry! Commonwealth indeed does not allow replies to be more than a 3rd layer in responses counting from the original post.
I’m curious about the “profit” we would make in gas savings. If it is substantial, then it becomes quite interesting for the long run. If marginal, then we must wonder if we should do it, combined with the additional load on hardware and governance. Plus that I can imagine that on the long run we would have multiple contracts wanting to be in the same spot.
Would there be disadvantages if we have multiple contracts pinned (if possible)?