Increase of Minimum Gas Fee - Part II

Dear Celo Community,

Thank you all for the input provided on our original proposal and your contributions to the constructive and open discussion. We have tried to integrate these comments into an updated proposal, which is now merged into the governance repo here.

We will present this proposal in the governance call on THU Dec 8 as announced here.

The quick summary is as follows (and the details are below):

  • We propose to increase the min gas threshold to just 0.1 cents for an ERC20 transaction, meaning lowering it considerably compared to the original plan and aligning with some of your specific suggestions

  • We make clear that this increase does not go to validators - it currently goes to the community fund and we plan a further proposal to burn these gas fees soon (beginning of next year)

To ensure transparency I am leaving the original content at the end of this post.

UPDATED PROPOSAL

Definitions

Let

  • gas_price_minimum = the minimal gas price for a given block = a function of (gas_price_minimum of last block, utilization of the last block, gas_price_minimum_(lower_bound))

  • utilization of a block = (gas used in block) / (gas limit of block)

  • gas_price_minimum_(lower_bound) = a lower bound of the function gas_price_minimum beyond which it can never fall, even if blocks are empty

  • gas_price = the gas price specified by a user for a transaction

  • gas_used = the gas used by a transaction

  • base = gas of a transaction paid to community fund = gas_price_minimum * gas_used

  • tip = gas of a transaction paid to validators = gas_price * gas_used - base

Current Situation

Currently, gas pricing on Celo roughly works as follows:

  • Every block a gas_price_minimum is defined (accessible through the GasPriceMinimum smart contract). If the block is full (more specifically: exceeds the density target, measured in gas), gas_price_minimum increases, if the block is empty, gas_price_minimum decreases (until gas_price_minimum_(lower_bound) is reached). These increases and decreases can be exponential, and thus the value of gas_price_minimum can change quickly.

  • In any given block, only transactions specifying a gas_price higher or equal than gas_price_minimum are valid

  • The gas paid by users is split between validators (tip, see exact definition above) and the community fund (base, see exact definition above)

  • A user only specifies gas_price, which then defines tip implicitly (whereas base is defined by the protocol every block)

Note: this means gas on Celo behaves very similarly to gas on Ethereum, with the big difference that the tip is defined implicitly through the gas_price specified by a user and gas_price_minimum specified by the protocol.

Actual gas fees are currently almost always at the gas_price_minimum_(lower_bound). They only rarely spike up from that.

Proposal Overview

We propose to increase gas_price_minimum_(lower_bound) so that a simple ERC20 transaction costs around 0.1 cents or USD 0.001.

Note:

  • This increase only impacts the base, meaning that the validator rewards from gas remain unaltered

  • We are confident this increase addresses the issues we discuss under Rationale, while at the same time the proposed fees are so low that they should not interfere with most use of the blockchain

Rationale

There are three core reasons for this proposal:

  1. Ecosystem cost of transactions

As the creator of a transaction, the main (marginal) cost of any transaction is the gas users have to pay to get it included in the blockchain. Currently, gas prices on Celo are very low, transactions are virtually free.

The cost of a transaction for the wider Celo ecosystem has additional dimensions to it than the gas spent. Namely, every transaction needs to be processed by nodes and is stored forever in the Celo blockchain. Note that the processing needs to happen by all full nodes and not validators only. While it does not have an effect on the blockchain today, this will have consequences in the long term. We realized we never accounted for this scenario when gas prices were calculated and proposed.

Increasing the gas price would ensure that transactions which are processed achieve a higher minimum benefit (= the gas paid), which warrants the long-term cost for the overall ecosystem.

2.1) Stability and security of the network 1

Low gas prices allow actors to spam the network at virtually no cost. Currently, it would take time until the gas_price_minimum increases substantially, to stop the attack. Increasing gas_price_minimum_(lower_bound) ensures that such an attack is a lot more costly from the get go, even if it is only sustained for a short period fo time.

2.2) Stability and security of the network 2

An additional benefit is that higher minimum transaction fees can be leveraged to increase the health and security of the overall blockchain by linking the network token to gas spent (e.g., through a burn mechanism - see Future Changes) and, thus, render 51% or similar attacks more difficult.

Future Changes

We plan to propose to burn a substantial amount of the fees collected through gas fees by the blockchain.

ORIGINAL OLD PROPOSAL

The original older proposal and the related discussion can be found here.

4 Likes

Just heard this on the Governance call and am supportive.

2 Likes

Feels pretty steep for gas price to go from today’s min 0.1 Gwei to 22 Gwei all of a sudden.

Can this be set to a round number like 10 Gwei instead of a 22 Gwei value that just happen to be computed off of the current Celo price?

2 Likes

hi!long time no see diwu tweet!

I’d also be in favor of this more modest increase. Considering that 10 Gwei is already a 100x increase from the current value. So do not increase gas price to 22 Gwei, but to a lower value like 10 Gwei; or even 5 Gwei.

Some things to consider:

  • The lower the gas price, the lower the friction for users.
  • Simple ERC20 transfers are not the only use case for the Celo network
  • Currently we’re in the depths of a bear market, which will likely revert at some point. In the next year(s), the CELO price could realistically increase by a factor of 10. This would mean gas prices also 10x.
  • Some Celo apps (like GoodGhosting, impactMarket and [Redacted]) are centered around micropayments, and specifically chose Celo for this use case. At a certain point they become uneconomical.

To give some context. GoodGhosting deposits in a simple strategy take ~360k gas, and up to 1.5M gas for a complex strategy (e.g. Curve).
Let’s assume a 1.5M gas transaction at 22 Gwei: that’s 0.033 CELO. At current CELO price it costs $0.018. Let’s assume a user makes 6 transactions to complete a full game, that’s $0.11. If CELO price increases back to $5 each, that would mean over $1 to complete a full GoodGhosting game.
That is a massive increase versus the current ~$0.0005 to do the same. Such a high tx fee will likely offset any gains made by a user (unless the user is depositing very large amount of funds).


So I would argue against the point from the last governance call (Dec 8) that it would only have a minor impact on programs in the Celo community.

2 Likes

I noticed that on Alfajores the gas price already got changed to 25 gwei. Correspondingly, my testnet oracle reporters are chewing through Celo paying for gas very quickly.


It’s using about 3 celo daily per report * 3 oracle reporters, so 9 celo daily.
Previously, running oracle reporter didn’t really eat much gas.

I think jumping to 20+gwei all of a sudden is too steep, if the goal is to curb the spam TX, then I’d think using even 1 Gwei would curb that spam volume. Right now, the block spam TX are all running at 0.1001 gwei, so it would already make those spam tx 10x more expensive.

The spike was due a test that has since rolled back. Current gas price on alfajores is 5000000000 wei, 50x more than on mainnet.

This is the value I intend to submit on mainnet.

1 Like

5 gwei seem reasonable for me :slight_smile:

Hah, thanks, I was worried I’ll have to keep fauceting alfajores celo every week by hand.

5 gwei better than 25 gwei

Hi @matt, would you like to discuss this proposal in the governance call on Thursday?

Hey, we have actually discussed this in the last governance call and it is already up for voting

1 Like

Seems more razonable :grinning: :metal:

I came here to read before sending a governance vote. I’m seeing a lot of disagreement (mostly in the original post) here that isn’t well reflected in the current vote counts, which makes me concerned this might be ushered in despite some reasonable and somewhat unresolved concerns from the community.

I don’t really understand the “spam” argument. Who defines what spam is? Is it a little bit like “I know it when I see it”? If someone is griefing your smart contract to truly be DOS’d it sounds like a design problem. We can’t account for what all users are doing in all situations, and what looks like a nuisance to us could be a so called “legitimate” use case: a demonstration, a tinkerer using block production as a chronjob, arb or sandwich bots, greyhats, students, product developers, traders, keeper bots, and anything in between. All of these things are fine and healthy parts of an open blockchain protocol.

While designing blockchain architecture around some fixed gas cost is probably an anti-pattern, I’m not sure we should be saying “transactions are too cheap, let’s make sure we’re getting more of the “right” type of transactions in each block”. We simply don’t know who’s activity this change will affect.

My understanding is that as per Ethereum, there is a gas fee market if we are truly filling up blocks, everything should be handled dynamically? If the so-called spammers are filling every block wont they be raising the effective minimum dynamically through the gas-market? “Real” users will have to fight them for inclusion and the effective minimum will rise with use?

So to give this proposal some a shake, regarding Rationale 2.1) can we get some evidence of the spam and what products are being interfered with? I was around for the transaction neutrality argument in the early Bitcoin days and it was fairly contentious there also.

and Rationale 2.2) is basically… remove more CELO from user’s wallets so number go up? And then this section references 51% attack protection as one of the outcomes of a higher CELO price. We’re running proof of stake here - is malicious group configuration and someone taking over 2/3+1 of the elected validators a real concern?

I’m down for some number go up but both these items feel somewhat unscientific.

1 Like

It’s really important to me and many here to work hard to keep transaction costs low so that Celo can deliver on the use cases that matter most to us.

There’s two scenarios here:
(1) now, while those apps are new and usage is growing, and there is spare capacity on the L1.
(2) in the future, when those apps are truly realizing their potential with millions of users.

This proposal is about situation (1). I see this as a bit of a “correcting a misconfiguration” kind of change. In the event that blocks are not full, there is a still a per-transaction cost to validators in terms of compute and storage, and the whole idea of gas is to reflect that.

My opinion is that a fee for a stabletoken transfer of 0.1 cent of cUSD is still so comfortably low that any app it makes sense to build on Celo should be able to accommodate it, and if not, it acts as a nudge for that app to think about restructuring their smart contracts or app design to make that possible. It still means Celo transfers would cost around 50X (!) less than Polygon, BSC, Optimism and others.

This proposal is mostly orthogonal to (2). The way to solve for the future is scaling transaction throughput – and that has been a major focus for the cLabs roadmap proposal we just published – to enable Celo to scale both vertically (faster L1) and horizontally (rollups). Without that, tx fees will be WAY higher than either the current or proposed base fee. c.f Ethereum. In the long run, I feel that this is the much more important question to focus on, since (2) is what we are all working towards.

2 Likes

Thanks @tim that makes it much clearer, so it’s more “it wasn’t configured as best it could have been at genesis” than “griefing the network has no material cost”.

Cheers