Gov controlled min gas price

Currently, each Regen Network validator can set it’s own gas price.
Gas is a unit used to charge for operations related to transaction processing.
Gas price is a price in Regen for a gas unit.

Problems with current solution

Validators can set any gas price they want. In particular: it can be zero (or negligible small) or very high.

Problems with zero gas price

I think zero fees is a bad solution. It’s same as quantitative easing the banks are doing now:

  • banks is printing money to companies until people will generate enough cash flow (spending)
  • blockchain is printing tokens to block producers until people will generate enough transactions

Fee must be present in the system to protect against:

  • spam (once we have it we will need to deal with it forever unless we break some of the blockchain principles)
  • economy stability

Non responsible validators, setting too small gas price can expose whole network to easy spamming. This happened in Q1 for Terra blockchain - it encountered sever spam attack.

Problems with abnormal gas price

Validator, setting a very high, abnormal gas price, doesn’t contribute to the system. He will not process many transactions, and only take

Note: this is not that dangerous as an irresponsible validator setting negligible gas price.

Other related issues

Fees problems were largely discussed and enumerated in the Cosmos community. Here is a meta issue collecting related threads.

Set sane minimum gas price #284

Proposal

We can set a governance controlled min-gas price and optionally max gas price:

  • chain_min_gas_price will be a lower bound for the validator gas price ( minimum-gas-prices in the node config). It should be really small - to really a spam transaction attacks.
  • optionally, chain_max_min_gas_price - an upper bound for the minimum-gas-prices in the node config).

This will be protected by the protocol. So each validator will be rejected by consensus if he will apply gas price out of the range set by the governance.

Consequences:

  • Changing min gas price (and max gas price if we decide to apply it) will require a proposal and voting. This is slow process and requires stakeholders engagement.
  • Min gas price should be rather small to hedge against Regen token value fluctuations. We really want to exclude negligible small gas prices which would cause network spamming.
  • There are better solutions (eg eip-1559) to be implemented by the Cosmos community, however it will take time (most likely we won’t see them in 2021).
1 Like

Great, thanks for the background.

We can set a governance controlled min-gas price and optionally max gas price.

How would this be done? Technically?

Are we discussing a governance change to Auth Parameter TxSizeCostPerByte ? But it doesn’t seem to me that this sets a limit, just a cost.

Or a change to SetMinGasPrices in Regen Ledger baseapp? But that wouldn’t be an on-chain governance change. /app/regen/cmd/root.go:

Or something else? Must be something else.

Thank you

In e-Money we have a network controlled min gas price (the one set in app.toml is ignored) so that transactions can be processed immediately upon receipt no matter which validator is proposing. Is this how you’re thinking to achieve it? I’m not sure that’s necessary for Regen usecase (i.e. for instantaneous transactions anyway).

Would a max min gas price just be easily circumvented by setting a high min gas price on your sentries as well?

Haven’t read through your supporting links yet so will do that and think more about it.

2 Likes

One question for me is: when do we want to legislate changes, versus when do we want to leave it up to participants to determine best practices? This is a question about bureaucracy. Maybe zero gas prices are bad, but do we want to prevent validators from using them if they see fit? My comment here isn’t about this specific issue, but more about community process and rules-setting. Sometimes it might be better not to have more rules, even if those rules make sense.

3 Likes

No, The TxSizeCostPerByte is the amount of gas charged per byte of read operation.
Gas price is amount of Regen charged for per unit of Gas.

What I’m proposing is to have a gov controlled parameter: chain_min_gas_price, which will be a lower bound for the validator gas price by setting minimum-gas-prices in the node config.
Validator will still have a freedom to set a higher gas price (if we decide to set an upper bound then (s)he can set it up to the chain_max_min_gas_price).

  • Ideally, the chain_min_gas_price should be very small to really reduce the spam transactions (we will always have spam transactions)
  • chain_max_min_gas_price should be rather high to limit selfish validators.

let me know if my response above answers your question.

I was thinking about it. Gov process is also a good opportunity to educate the community (like in a real world referendum).
I don’t expect that we will need to make many proposals changing the chain parameters for min validator minimum_gas_price. It’s more on setting something very small to avoid attacks to the network through irresponsible validators, or sabotage validators.

Thanks for your reply. But sorry, I’m still not fully understanding.

The part that I’m looking for more clarity on is “to have” … how is this “had.”

What are the actual code changes that would need to be executed and in what code base?

The idea sounds great, but without an understanding of the implementation, I personally can not form an opinion.

But it sounds to me like, you are suggesting that we can add a new gov controlled parameter to our chain. Which, to my limited knowledge, is not possible.

Currently, these are all the gov controlled parameters available: Cosmos Hub Parameters Index

So I must assume that we are not actually discussing on-chain Cosmos Hub Governance Parameters.

by setting minimum-gas-prices in the node config

“In the node config” explains more, so the minimum-gas-prices in the validator node’s configuration would be a voluntary compliance that each validator would need to agree to and update their settings accordingly, based on an off-chain community agreement?

And each validator would set this in their app.toml file?

Is that getting closer, or is there still something I am missing here?

Thanks!

Here is an example of how I did it. It took me 20 minutes to copy and modify the code.

1 Like

Hmmm, interesting. Thanks

So perhaps we are discussing changes to the AnteHandler in regen-ledger code base: regen-ledger/app/app.go

So each validator node would need to upgrade to the latest version of regen-ledger for the changes to take effect, correct?

Thank you

1 Like

yea, that would be the only way for this to happen. Not sure if there is any other way.

1 Like

The update will require:

  1. Gov voting to make appropriate change in the code (adding a new parameter and setting to a initially proposed value)
  2. Update the code (similarly to what @marbar3778 presented): adding new param and adding new antehandler
  3. Deliver new version for the network and see if 66% of validators will approve it. Any software update must go through the same process: release new version and wait for validators to update. BTW: there are tools to automate this.

Currently, these are all the gov controlled parameters available: Cosmos Hub Parameters Index

Those are parameters for the Cosmos Hub. Each Cosmos chain can define it’s own parameters

“In the node config” […] each validator would set this in their app.toml file?

Yes - this is how it works today: each validator sets it’s own min gas price. If, in your transaction, you will set a lower gas price, then the validator will accept it. So you must hope that there is a validator will accept a low gas price. However, setting zero gas price will make a transactions for free. So you could send 1 regen between two accounts back and forth for free and spam the network or even DDoS it.

1 Like

Wow! Awesome! This is what I wasn’t aware of. Now I understand. Thanks!

And my opinion is that a minimum gas fee / tx fee is pretty much a necessary requirement for any blockchain’s security. There are operational costs, nothing is free.

1 Like

I would like to note that included in this bundle of conversation should be an analysis of Akash and Persistence and Osmosis PoS designs that limit block rewards to a time period, then expect the network to have enough transactions to pay for security.

Can you offer a little context and some links for me to understand how this is being thought about at the Cosmos SDK level? If I am not mistaken Aaron has been socializing some changes to the SDK in this direction.

that limit block rewards to a time period, then expect the network to have enough transactions to pay for security.

I’m not sure if this protects the network against spam attacks. It’s not about rewarding - it’s about making sure users will pay some small minimum amount fee so spamming / sending 100mln useless transactions won’t be profitable for the trolls.

Sure. This discussion (is burried in the meta-issue linked in the OP) has most of the related information. I was part of the research group to evaluated different solutions. It turned to be very important during the Terra spam attack.
We agreed to eventually implement eip-1559. However there is no available team to do it. Through rough estimates it will take 5-7 months. Moreover, in the meantime issue to prioritize certain type of transactions (slashing evidence, IBC) popped up to be as important and it will impact the eip-1559 implementation. There is a chain (forgot which one) which wants to have free transactions. Also, there was no clear consensus on what should be the default for SDK, and hub wants to push to algorithmic fee design. Most of the stakeholders think that someone is working on a solution, but nobody is doing it because aforementioned TX prioritization queues must be speced and analyzed first.

The only consensus we achieved was to error on empty minimum_gas_price config - which in fact doesn’t protect against sabotage attack. For networks like Ethereum this is not much problem because there is so much upfront cost to create a block, and one block has only 150-200tx on average. And there is only one block per 12 sec. So spam attack on Ethereum 1.0 is not economically viable.

In the meantime, would it make sense to require validators to set a minimum fee on their sentries before being eligible for foundation delegations?

I don’t see an issue if the validator itself allows zero fees (so that validators can submit 0 fee transactions to their own validator) however a test could be performed automatically and periodically to send a zero fee transaction through the network and any validator that picks it up will be cautioned.

I know this didn’t work in the Cosmos Hub but isn’t the participation in Regen Network from the validators a little closer?

How do you want to caution a validator? A gently note?

What if in a meantime someone will sent 100000 spam transactions?

Haha, what about a very angry note?

But seriously, removal of foundation delegations should be enough. It should kick many validators out of the active set even. I think the Regen validator community is much closer than the Cosmos Hub one was at the beginning.

Anyway, I’m just talking about for the time between now and whenever any code modifications have been made.