In Protocol Gas Price | Fee

[tac0turtle]

In the Cosmos-SDK currently it is trivial to send 0 fee txs. It is recommended to increase the min fee to help avoid spam but many validators do not do this.

An approach of base fees by msg type could help in avoiding 0 fee tx spam. For example a bank transfer will require x fee based on computation resources or if the app developer wants to charge a specific amount. Once the chain is live any transaction will require the predefined base fee unless set to 0. This base fee could be computed by writing a simple test or benchmark and the output copied into the msg handler, but it would always be consistent and known ahead of time.

Later on an extra fee can be added on top of the base fee in order to speed up the transaction, this will be used for when Tendermint introduces priority. But for now it would mean no more 0 fee transactions, unless the app developer says.

This is a similar approach to how substrate introduced transaction fees. You can read more about it here: https://substrate.dev/docs/en/knowledgebase/learn-substrate/weight

[alexanderbez]

There is already an issue and agreed upon approach to this -- #4527. Not sure we need to have this discussion here unless you have strong opposition to #4527.

[hxrts]

• LazyLedger is looking into EIP-1559 implementation
• Escalator algorithm is the main proposed alternative to EIP-1559
• Combination of EIP-1559 and escalator
  

I am currently writing an RFP about modelling this problem in the Cosmos context. In particular, we need to better understand how validators accepting fees in any denom effects security (not just spam prevention).

Burning exogenous tokens for gas fees strikes me as bizarre, though technically possible. Requiring an ATOM base-fee burn breaks the main UX benefit of fee choice. I suppose a middle path would be automatic AMM conversation of fee tokens into ATOM, a portion of which would be burned, though this has its own drawbacks. cc @sunnya97 @ebuchman

[ebuchman]

Yep I think right now at least for the Hub I generally lean towards EIP-1559 style approach in the long term with fees payable in any token with a "large enough" pool in the Hub's AMM against ATOM, then swapped to ATOM and burned/tipped appropriately. This was a motivating reason for me for the Hub to have an AMM. Though we'll probably want to do some modelling to understand the risks of that better. Also I haven't looked closely yet at the escalator nor the Ava approach.

That said not sure if we need something else in the meantime. At the very least Tendermint mempool probably shouldn't be FIFO, but somehow allow for ordering and shedding txs based on "priority"

[hxrts]

This paper compares all three approaches and their trade-offs. Did a closer read today and as far as I can tell it's the best reference out there. I'm leaning towards the same, EIP-1559 with DEX conversion into ATOM for burn.

[zmanian]

This should work for Terra as well but we should ask them.

[robert-zaremba]

EIP-1559 with DEX conversion into ATOM for burn.

Yes, this is good, but it's important to note that this will create a dynamic market (deflationary / inflationary) for all chains.
Also, this will take way more time to do it rights so... we need something in the meantime. This will also add an option for chains that will not like to optin for dynamic fee aproach. For example, it won't work for chains with fixed coin supply (not sure if there are any in the Cosmos Ecosystem).

[robert-zaremba]

Zero Fees

yes / no?

[robert-zaremba]

(reposting my message from Discord)
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

That being said the two driving forces may be conflicting if there is not enough demand :

1. Miners must be incentivized to not do censorship and include as many transactions as possible
2. Users have to pay for the work (or trade off something else).

I don't think we need to reinvent the world here. There was enough research in various blockchains solving the fee dynamics.

[robert-zaremba]

Simple, Static Gas Price

The easiest one to start with is:

1. static (fixed) gas price set by a blockchain governance (governance can update the fees). Works until the blockchain will get congested.
2. An interesting variant is to have a consensus wide minimum gas price. It's interesting because it enables quicker changes.
3. NOTE: non zero fees in blockchain with locked assets may be problematic: users may not be able to participate in the governance. A solution for that is to enable zero-fees governance for token holders who are locked or have a special dispenser or x/feegrant.

[robert-zaremba]

Algorithmic Fee: Basu, Easley, O’Hara, G ̈un Sirer 2018

I really like the approach presented by Cornell University without generalizing to any specific projects). The main idea here is: miners have a penalty if they don't fill a block up to a given factor K. The factor can be adjusted by a governance (so at the beginning it can be close to zero). All transactions pay the same fee = the lowest fee in the block. Doing this naively unleashes an attack vector, where the miner is adding "artificial" transactions and removing the lowest one. The remedy is: the miner has the option to fill the block to capacity with transactions, but only K of them are priced using this auction mechanism.The other transactions are charged no fees for being included in this block.
The reward for a miner’s payment from transaction fees must incentivize the miner to not manipulate the contents of the block and to place the highest paying transactions from the mempool into the block. To deal with both concerns, we set the miner’s reward to be the average revenue generated over the last B blocks, including the block that the miner has just mined. The miner is incentivized to place the K highest value transactions into the block for two key reasons.
First, the miner is receiving a fraction of the rewards in the block that they recently mined.
Second, miners are paid in the underlying cryptocurrency and they typically maintain a position in the cryptocurrency. So, they have an incentive to make the cryptocurrency successful, which incentivizes them to put high value transactions into the block.
https://arxiv.org/pdf/1901.06830.pdf

[robert-zaremba]

Meeting Notes 2021-03-09

Framing

Min-fee (spam prevention) vs base-fee (price predictability + MEV harm reduction)

Key takeaways

• Currently Gaia blocks are mostly empty (~50%?). We think this will change once there will be more modules on the Gaia Chain.
• We need to check more with the big cosmos chains: Crypto.com, Terra, Thorchain - how they see the problem with fees.
• Although, currently not a problem for many chains, zero fees may cause problems and it's always harder to extinguish the fire than preventing it.
• We are missing tools to make quantitative decisions about fees
• It's important to move this forward rather than waiting for problems.

Concerns

• zero fees could be exploitable if there are expensive operations (eg: high storage, high CPU)
• IBC introduces a lot of state to the hub. Clients are going to be a big part of IBC. IBC doesn’t really care about fees but does want prevention of spamming / DOS vectors
• Fee model should be plug-gable - different blockchains may have different requirements
• Correctly aligning incentives between the users and validators are important:
  • we should prioritize censorship resistance and keeping the blocks full
  • validators should be penalized (dis-incentivized) to keep fees to high
  • risk: validators can produce empty transactions (even with fees, if the fees won't be burned and go back to the validator)
  • economical model must take into account a mechanism to process as many transaction as possible yet
• single denom fees vs multiple denom fees
  • multiple denom fees may better reflect a cost of different resources. However they are more complex in terms of UX and implementation.
  • UX problems with multiple denom fees could be solved with DEX or AMM.

Solutions

• Sunnys' Validators with Medianizer - every validator can signal what they think the min-fee should be and we take a median of it. A fairly sound and simple proposal. Could be delegate to a 3rd party.. Problem: we don't put user and censorship resistance into equation.
• Regen: Validators can set individually minimum fees. Problem: as above, you can’t actually query what the min-fee is.
• Setting a fee in state machine and updating it using x/gov. Problem: too slow (may not adapt on time when network spikes).
• Algorithmic approach (eg: EIP-15519)

Summary

Single denom fees with a validated algorithmic approach seams to be the most solid approach. EIP-1559 is validated by Ethereum and should be good to go.
Next up: check the proposal introduced by Robert to get more opinions vs EIP-1559.

Ref: https://hackmd.io/xuO33vnlQcao30CeCXtr-w

[hxrts]

Meeting Notes 2021-03-16

---

• actionables from last time:

  • build in sane default into the binary
  • disallow zero fee (except for specific operations that require zero fee like delegator withdraw)

• are these relatively trivial changes sufficient to address spam problems Regen identified in the next 6-12m before we can deploy a more substantial solution? unclear.

• authz module in 0.43 can blow up state because operations are not financially costly

  • Regen considering small bond amount for authz operations which may be refunded (or fee burn). similar to state rent, but short duration.

• sunny's proposal: base fee that can be changed via validator signalling OR governance

  • doesn't handle multi-denom well, requires validators constantly update multi-denom pricing. validators would almost certainly automate this vs manually touching their node meaning validators are relying on external price feed which seems like unacceptable security model
  • could this be used in conjunction with elasticity based on number of non-emty blocks? seems like we're basically reinventing EIP-1559 now. may as well do EIP-1559.

• for multi-denom, what denoms should be accepted? any? whitelist by gov?

  • receiving chain will already have a list of denoms from chains that have at one point connected to the chain
  • if receiving chain has an AMM, markets with some liquidity threshold can be accepted

• zaki: we should ship single currency with sdk, teams that want multi-denom can figure out on their own

  • creates IBC UX issues for users: how does someone on Regen obtain ATOM to pay the transaction fee to use the DEX? All chains now required to have local AMM with liquidity.

• misc ideas

  • small client-side proof of work puzzle - probably some UX issues, particularly on mobile. might be viable otherwise.

[faddat]

1. Fees are always good. -- if authz can burden the network, it should have a fee/deposit.

See:
https://www.coindesk.com/how-blockchains-become-great-big-garbage-patches-for-data
https://blurtter.com/blurt/@jacobgadikian/blurt-propaganda-jam-session-001

2. Validators are like elected officials and can be used to make executive type decisions. It's okay to have them or governance make changes to fees.

3. I do not favor the small client side proof of work puzzle, heard it proposed many times, never seen it work.

[robert-zaremba]

Fees are always good. -- if authz can burden the network, it should have a fee/deposit.

Yes, this is where we (Regen) are heading into for storage management. However, this won't solve zero fees problem.

[robert-zaremba]

To complete the notes:

We have two separate discussions here, and IMHO we should focus on one first:

• multi denom fee payments.
• zero fees.

On the importance of zero fees

I was proposing start with single denom gas price (and @zmanian strongly seconded that) and tackle the zero fees on a consensus level. Multi denom, can be done later or even in parallel.
As discussed, we can start with a simple solution for zero fees: fixed gas price + governance to adjust it + some dispenser for locked accounts so they can vote is a simple and good enough solution. The low hanging fruit.

Starting with fixed gas price will provide an economic defense to prevent spam transactions.

The argument against fixed gas price + governance adjustment, is that it is not responsive enough. However, if there will be a spike in tps or spam attack, the originator / attacker will need at least to pay for that.

In the meantime we can have a working group which will analyze different transactions and it's impact on CPU + storage to better adjust the gas levels and do dynamic gas price mechanism.

How about dynamic gas prices?

As pointed out during the meeting, picking on ERC-1559 will have much bigger economical impact: it will add another parameters to the ATOM supply and will make it deflationary / inflationary based on the usage. This is not something we can decide in a week or enforce it for all chains.

[cmwaters]

Just a clarification on the fixed gas price idea. Does this notion set a constant price throughout the entire network or just sets a network-wide lower bound on the gas fees?

[robert-zaremba]

@cmwaters - for fixed gas price: the minimum vs fixed could be seen as a parameter in this model. Enabling or disabling a mode (minimum vs static) could be switched by a governance.

[aaronc]

To address deposits specifically, I've proposed an x/deposit module in a separate discussion: #8929. Let me know your thoughts there.

[robert-zaremba]

If you think it's worth to track it in the meta issue, then you can add it here: #8917

[hxrts]

Thanks for writing these up. One question: do you see either solution still having value if we were to later implement a base-fee burn or similar? Do we want an additional disincentive for state writes?

[robert-zaremba]

I think it makes sense to charge differently on resources which are reserved (like storage) beyond the transaction lifetime. Fee burn doesn't solve that.

[hxrts]

Cool. This is my intuition as well. Seems to fit within the spectrum of state rent proposals. Perhaps we can create a unified pricing scheme.

[faddat]

The medianizer is exactly what we do at blurt and I have been consistently happy with our fee setup.

The medianizer solution is market oriented and reflects the reality that validator's are vendors of block space.

"What if fees aren't low enough for users?"

Validator's are in just the right spot, economically speaking, to really really care about adding value to the network.

They're better informed than most token holders, and possess the information needed to make the right choices.

+💯:

Medianizer.

Just need to make sure that every tx type is covered by fees, quite carefully.

We did 2 types of fees:

• Per tx
• per kb

Witnesses (they're just validators) choose these values and the network takes the median.

This also means that the chain can rapidly respond to adverse events.

Lastly fees show clear demand.

Giving the tx'a away free does nothing to support global perception of Gaia/atom/cosmos.

I know eth fees suck, I'm a user, but at the same time, a single trade can cost $60 and I'm still a user.

That's validation.

[alexanderbez]

I've already proposed an idea similar to this, but unless I'm mistaken an approach like this can be gamed, in that a proposer can select which txs get included based on their fees allowing them to skew the current in-protocol fee.

Note, the SDK already charges fees for tx size and for the tx execution itself.

[robert-zaremba]

We propose deposits / staking to charge per storage used -> #8929
I think this should also include some mechanism to compute the new storage created by user. How do you solve it @faddat ?

[faddat]

On Blurt we think only about the size of state that is committed to the chain, and compute fees based on that.

Everything is per-kilobyte, and we don't think about the compute cost.

[robert-zaremba]

Meeting Notes 20 April 2021

Storage Deposits / storage staking

• We clarified that the storage deposit is not spendable as gas -> there is no gas
• We don't have and don't plan to have a gas redemption when releasing a storage (which would allow to create a gas token). We think this is not a right mechanism and it's not sustainable (idea of locking a big chunk of storage for future uses).
• in the Deposit Module #8929 (comment) there is no token and deposits are released as the resources are released. The deposits itself are not tradeable, but the they are using the native token.
  NOTE: one could create a module to trade the storage deposits - but then it would be the intention of the blockchain designers.

Dynamic Fees

• @hxrts read through the EIP-1559 whitepaper and gave an assesment of it.
• @robert-zaremba read through the AVAlabs / Cornell whitepaper and gave an assesment of it.

Summary

EIP-1559 has better economic guarantees. Inherently it creates a dynamic (inflationary / deflationary) token supply mechanism. However we found that this can be changed and have a stable token supply. Fees are predictable and depend on the network activity. EIP-1559 has the tip mechanism (transactions tip the block producers to buy the block space) to prioritize more valuable transactions (those which can yield more welfare) - transactions with higher utility would naturally pay a larger fee to miners.

AVAlabs fee model is way simpler and doesn't impact the token supply. It effectively implements the medianizer idea we were discussing for a while. Moreover it's much simpler. Participants are still bidding for the block space and have the ability to prioritize more valuable transactions (as in EIP-1559). Opinion: based on my analysis (Robert) it provides better price predictability than EIP-1559, because everyone will pay the lowest fee. So even if a one transaction will have a high gas price attached, it will only pay what's needed to be in the block, creating a fair Bayes-Nash equilibrium.
However, AVAlabs fee model economical stability requires active blockchain participation - it assumes we can have a stable K (block fulfillment) parameter and that there are many participants to fulfill blocks. If there is not enough participation, the block producers may pay penalties (or fake small transaction - in that case they will still need to pay (K-1)/K fees of that fake transactions).

Conclusion

We pick EIP-1559 as a more stable and future proof mechanism.

Followup
We still need to decide what we are going to do do in the meantime.

Multi Denom Fees

I found that AVAlabs mechanism could be use to have multi denom fees controlled by block producers:

• We could use that to allow transactions to attach gas fees in other currencies
• As in original model the fee is an average of last K blocks based on the second auction model of each block (in fact it's not strict second auction, but the lowest of the all bids which made to the block).
• Miners will either accept it or not. If there are enough transactions we would explore a gas price for multidenom by creating a gas price market for it.

I think it's an interesting mechanism, but relays on the same assumption: we need to have enough activity in the blockchain.

[robert-zaremba]

NOTE: I've update the post above by adding a idea I've got at the end of the meeting about the transaction market for Multi Denom Fees.
cc: @hxrts

[hxrts]

Thanks for writing this up Robert! I agree multi-denom is possible with the BEOS mechanism, but the exchange rate pricing introduces the oracle issues discussed previously, i.e. validators ultimately depending on automated price feeds.

And regarding price predictability, users don't know prior to block finalisation how much they will be paying, most will get refunds.

Anyway, really appreciate your comments throughout this process and I'm really glad we went through the exercise of convincing ourselves of the trade-offs. I also think it would be very cool for another team to implement this fee mechanism. I'm all for a variety of fee experiments in the ecosystem!

[robert-zaremba]

validators ultimately depending on automated price feeds.

So, in the idea I presented, there is no need for additional oracles or DEX - the transactions and validators will create a market (and become an oracle). In other words: the validators will define the min fee for other denoms (as they will do for the native coin), and we will use same mechanism for gas price discovery in native coin as well for other denoms.

[robert-zaremba]

Proposed Roadmap

1. ADR for short term solution (we won't get eip-1559 implemented anytime soon)
2. ADR for eip-1559: with discussion and solution about token supply dynamics (probably it must be controllable)
3. Implementation of (1.)
4. In parallel to 1-3, implement (2). Since the implementation of (2.) will take 6 months, we should have enough time to clarify edge cases and ADR for it.

[hxrts]

My understanding is that 6 months is probably about the right timeline for the hub requiring this, Terra already has a hacky min fee so likely doesn't need it in the immediate term. Let's pick this up on the next call though.

[robert-zaremba]

Today, Ian mentioned the eip-3298. It's a good reading on why the storage refunds doesn't work, and it is in line with our thinking to avoid any gas price manipulation using storage / resource fees.

[robert-zaremba]

Status update

• We don't have any actions planned to move forward with EIP-1559
• Main focus drifted towards tx mempool prioritization, which will impact the EIP-1559 implementation
• we are checking with community to implement min gas price with governance for Regen Network.

[faddat]

"Min gas price with governance"

👍

-- I am unsure that it should be the token holders choosing, however. Realistically, validators bear the costs of transactions, and perhaps they should be the ones setting tx fees.

[robert-zaremba]

Validators will set it's own min gas price. Token holders / gov will set the minimum a validator will can use for it's minimum gas price. Sorry for confusions - it's a bit twisted.
Optionally we could extend the idea and also use gov for mx gas price.

[faddat]

actually, this is good. Let me repeat it back to you to make sure I've got it:

• Tokenholders set universal minimum for the blockchain via gov
• Validators individually set their own minimum

[robert-zaremba]

@faddat - almost. The second bullet point must be: _validators individually set their own minimum gas price which must be bigger or equal to the gov minimum gas price`. I use the following names:

• chain_min_gas_price -- the lower bound for minimum_gas_price set by gov
• minimum_gas_price -- the effective minimum set by a validator, must be chain_min_gas_price <= minimum_gas_price

The chain_min_gas_price should be really small to protect against irresponsible validators or sabotaged validators.
See here for more details: https://forum.regen.network/t/gov-controlled-min-gas-price/213

[robert-zaremba]

In most use cases allowing zero gas price is bad for the network, and exposes a chain for a serious spam attack. However there are few use-cases where we want zero-gas prices - where a private node will pay for it's "customers". However, IMHO we have a better solution for that: authz module.

[tomtau]

FYI EIP-1559 #10463

[robert-zaremba]

Fees and Gas prices.

This is a new thread to re-discuss fees vs gas prices and tx prioritization. Related to an architecture call today. Vocabulary:

• gas amount = amount of gas units charged for operations / messages
• gas price = a price of gas unit, charged when processing a transaction

Let's define requirements:

1. Certain transactions (eg evidence or IBC) should have higher priority compared to others
2. We should have more flexibility of defining fees.

If I understand @zmanian correctly, there is an idea of having a flexibility for assigning different fee mechanisms to modules or even functions.
The idea of EIP-1559 is to have the protocol wide gas price mechanism. I think, involving different gas price models into a single runtime may break the model economics (eg, having a fixed, very low gas price for IBC may impose an attack vector when all other transactions are way more expensive). Moreover it will significantly complicate the design (we will need to have different gas units).
Instead we can consider the following:

• Use an app wide gas price model.
• Operate on the gas amount model rather then the gas price. We can always factor out the gas amounts for preferential transactions rather than changing the gas price.
• With the current middleware design we created, it's easy to calculate the priority of a transaction using both the fee and transaction type. We can even create quotas per block (eg definitely prioritize evidence transaction unless they will consume more than 5% of a block, similarly IBC transactions unless they consume more then 30% of block)....

So, I would prefer to clearly separate the gas fee model and tx priority from the gas price model (eg EIP-1559, or the current one min gas price / validator).

[alexanderbez]

I'm not really following the concern. How does it cause issues? fee = gasPrice * gas. What's hard to understand about that model?

[iramiller]

Re-reading your comment and the above it appears that maybe your meaning was removing the term "fee" from gas calculation terms (price/amount-of-gas) only which I agree with.

A fee on a tx is more than gasPrice * gas ... I view it as fee = resource-costs + prioritization + business-value-assessment. Leaving the term fee for the overall calculation result makes sense.

[yihuang]

evmos/ethermint#830

FYI, when testing EIP-1559 in ethermint, we found some conflicts between baseFeePerGas and minimal-gas-prices.

[robert-zaremba]

So, I see that gas fee is a bad term for my vocabulary. I will use gas_amount instead.

[tuloski]

I agree that the gas_amount should be related to operations only, and it should be deterministically calculated.
The real cost of the transaction is instead determined by the gas_price which is dynamically modified based on network usage.

I don't agree BTW on having prioritized transactions based on transaction fee (gas_price). I think we should have a lower threshold so that if gas_price paid > gas_price threshold the transaction is included in the consensus round, otherwise discarded.
And the ordering of transactions should not be FIFO, but something like XRPL canonical order (https://xrpl.org/consensus.html), so that every transaction has the same chance to be first, avoiding frontrunning and other bad mechanism as in ethereum. It would be an overall fairer system for everyone, not giving priority to frontrunners or BOT which can pay high gas_price.