[PROP #3][APPROVED] Reduce the value of TxSizeCostPerByte

Dymocracy
1

Status

Approved

Authors: validators Yep++ aka alphab.ai and MZONDER

Since the launch of the Dymension blockchain (chain-id: dymension_1100-1), transactions have been consuming a significant number of gas units. This is particularly evident for ibc-relayer operators, who spend a significant amount of DYM per day on fees for servicing ibc relayers. Upon investigation, we have concluded that the main issue lies not with the min_gas_price, but with the auth.TxSizeCostPerByte parameter.
We consulted with the Core team and received their confirmation.

Comparison of auth.TxSizeCostPerByte across different chains:

  • Dymension (chain-id: dymension_1100-1): auth.TxSizeCostPerByte == 100
  • Celestia (chain-id: celestia): auth.TxSizeCostPerByte == 10
  • Cosmoshub (chain-id: cosmoshub-4): auth.TxSizeCostPerByte == 10
  • Osmosis (chain-id: osmosis-1): auth.TxSizeCostPerByte == 20

Test results:

Testnet proposal to align with Mainnet: Proposal #7

Before: TxSizeCostPerByte(10) txhash #73976FB
After : TxSizeCostPerByte(100) txhash #9D85D52

Reducing the value of auth.TxSizeCostPerByte will lead to a decrease in the number of gas units consumed per transaction. Consequently, lower gas consumption will result in reduced transaction fees.

If successful, the proposed governance change will set auth.TxSizeCostPerByte to 10 gas units per byte. This adjustment aims to reduce transaction costs, particularly for large transactions such as ibc-transactions.

This proposal has a 24-hour discussion phase before going on-chain.

Thank you to all testnet validators for a help!

Link(s)

Governance votes

The voting period for this proposal as set on genesis is 5 days beginning from the time of deposit. The following items summarize the voting options and what it means for this proposal:

  • YES
  • NO
  • NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Dymension, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Dymension governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
  • ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal.
50 Likes
2

cheers guys! in support of this. :v:

12 Likes
3

That’s a great suggestion. Especially, as in the example you provided, IBC transactions can be quite costly for operators. Implementing such a change in the early stages of the network will reduce the burden on them. I am looking forward to seeing this change implemented in the mainnet.

10 Likes
4

thank you all for your support and help :pray:
the proposal is now in voting period :boom:

7 Likes
5

VNBnode voted “YES” for this proposal.

4 Likes
6

Lucky voted yes. Thank you for proposal

5 Likes
7

By decreasing the overall transaction cost, what is the expectation on spam transactions and potential network congestions at some point down the line after this proposal has passed and implemented?

Any anti-spam mechanisms that has already built-in or will be implemented as a result of this proposal?

5 Likes
8

Great solution, well done :+1:
voted yes

3 Likes
9

as you can see other network has the same parameteres so nothing critical is expected.
As an anti-spam mechanism we have min_gas_price which can be adjusted individually by a validator. Currently as an agreement it’s equal to 5bn adym.

6 Likes