Reduce the Minimum Price of Gas (MPOG) for the Archway Network from 900 Gway to 140 Gway

Proposals
14

Just wanted to provide a bit more context to this discussion as I don’t believe the high gas costs @Tritador is getting for Gelatto threads is being caused by the MPoG per say.

A few thoughts come to mind:

  1. The are multiple issues that can lead to high gas. These are: i) pessimistic gas estimation / adjustment; from the dapp frontend; ii) code or storage complexity in the smart contract; or, iii) MPoG
  2. Given the above, to assess what’s causing high gas costs we need a complete picture of what’s happening. That’s why tx links are helpful (shout out @notRizbe)
  3. The contracts I developed (ArchID, Archies, and the Ambur and ArchID marketplaces) show that transactions, even somewhat complex ones, are actually way less expensive than what @Tritador is suggesting. In fact, to get a similar fee to what @Tritador is getting for Threads, I had to store well over 2000 chars of JSON in storage.
  4. It seems like we all mostly agree that MPoG should be lowered, the problem is deciding how much it should be reduced. To decide that we need to agree on what is a simple transaction and to what extent contract developers vs protocol developers are responsible when high gas fees occur (again tx links are helpful for determining this, but os smart contract code is even better :sunglasses:)

Let me provide an example to illustrate what I mean. Recently, I worked with an NFT team to determine why minting costs were ~5 ARCH (example tx). Here’s how that went:

  • We noticed the first few mints cost ~0.15 ARCH
  • Very soon fee costs grew exponentially and settled around ~5 ARCH per mint
  • After seeing some of their code, I recognized what was causing the high gas cost and how the original fee cost of ~0.15 ARCH could easily be restored

Imagine you have a storage state setup like this:

use schemars::JsonSchema;
use serde::{Deserialize, Serialize};
use cosmwasm_std::{Addr, Uint128};
use cw_storage_plus::{Item};

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct State {
    pub owner: Addr,
    pub cw721: Addr,
    pub whitelist: Vec<Addr>,
    pub whitelist_allowance: u64,
    pub mint_price: Uint128,
}
pub const STATE: Item<State> = Item::new("state");

Now imagine your whitelist has thousands of members stored in it; every time you load your STATE in a tx, the validator node loads that entire whitelist vector into wasm vm’s memory. This exact issue is what caused the mint price to increase to ~5 ARCH.

Okay, that’s cool but how do we reduce the fee cost back to ~0.15 ARCH? To reduce the cost we need to remove the whitelist attribute from the main STATE structure and move it to a key value pair storage keyed by user address. After making that change a validatator will never need to load the entire whitelist into memory because users can be verified by checking if their address exists as a key in the new whitelist storage type.

The change could look something like this:

use schemars::JsonSchema;
use serde::{Deserialize, Serialize};
use cosmwasm_std::{Addr, Uint128};
use cw_storage_plus::{Item, Map};

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct State {
    pub owner: Addr,
    pub cw721: Addr,
    pub whitelist_allowance: u64,
    pub mint_price: Uint128,
}
pub const STATE: Item<State> = Item::new("state");

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct WhitelistMember {
    pub whitelisted: bool,
}
pub const WHITELIST: Map<&Addr, WhitelistMember> = Map::new("whitelist");

This very simple code change will reduce their tx fees from ~5 ARCH to ~0.15 ARCH, and I believe a similar optimization could be required for Gelatto threads because there’s no reason for a simple upvote to cost ~0.58 ARCH.

As always, I am happy to help anyone review or optimize their code. You can hmu on TG at Telegram: Contact @richgirlonlsd or find me hanging out in the Archway discord :sunglasses:

3 Likes