Seems quite high, as $0.001 is 10% of 1 cent. We provide UBI to the most vulnerable communities and transfers of few cents on a dollar is very common (which is very different when considering local currencies). I agree that Celo should increase significantly the gas prices to also improve its economics and benefit all the ecosystem, but $0.005 seems a big jump. Maybe first increase to $0.0005 and measure its impact before going for higher?
How would the humanitarian transaction be defined? Bellow X amount? If its something like min $0.005 or 1% (which ever is lower), I’m ok with it
Some thoughts on this that I also shared with some of you async:
If we are looking at protocol revenue (or burn amount in a EIP-1559 like mechanism) as revenue = avg tx fee * #number of txs (or R = p * D(p)), then purely from a protocol economics perspective it’s not clear to me that an increase in the min fee (p) would actually increase protocol revenue (R), considering that #number of txs (D(p)) is a function of tx fees (p).
In other words, I think we would need a better understanding of block space demand before actually concluding that this would work in the direction that is outlined in the proposal. So I’m wondering if there was any further analysis in that direction.
I know that this is a difficult empirical question but maybe there is something to learn from current tx pricing. If e.g. the current avg fee is close to the current min, then it would suggest to me that a further increase would actually have an adverse ‘volume effect’. If the current avg fee is consistently above the current min, I think its fair to assume that there is some room for an increase.
thanks for the feedback on implementation steps, I agree with letting users know early - it is almost a given as changes at the core blockchain layer need to be agreed upon (and discussed by) the community. which is why I started this thread here too.
My intepretation of the project’s goal was always to keep transaction fees below a cent – I think I had mentioned this number a few times before, eg this tweet. I do recognize there are a number of use cases that, now that minimum number has been lower for a while, are baking in that assumption.
The challenge is that a transaction on an EVM results in a bunch of resource consumption not just on validators (there’s an argument they’re paid separately) but on every full node. Setting realistic gas prices is really a denial of service prevention mechanism, and I think that the current values are set too low. Right now you can fill every entire block for less than 1 cent in total(!). I see this as a straight-up misconfiguration!
On a related note, it’s hard to make the EVM (on any chain, Celo or otherwise) scale to the throughput we would like. cLabs is actively working on some pretty radical ways of scaling performance, but until that happens, a situation where there is high demand for block space under EIP1559 will always cause gas prices to rise and remain much higher. So I would urge caution in baking in very low gas costs as an assumption.
To balance the concerns in this thread, how do folks feel about a minimum fee somewhere in the ~0.1 US cent range for an ERC20 transfer (based on current CELO prices)?
thanks for your comments - we’re working on an upgraded proposal here and will get back shortly to all of you.
Regarding your comments:
Yes we’re working hard towards higher throughput at Celo too. The lower bound of min_gas_fee does not apply if blocks are full, in that case the minimum increases (exponentially). The parameter we’re discussing here only applies if blocks are not fully used. And higher throughput, given everything else equal, means higher probability of space in the blocks - which will actually increase the time in which the regime is in the state of min_gas_fee = lower bound.
Note that increasing the min_gas_fee does not increase validator rewards. All this gas currently goes to thee community fund. For the future, we are thinking about introducing a burning mechanism instead so that Celo becomes deflationary in the long run.
EIP1559 already takes care of the argument that it’s too cheap to fill entire block.
Sure someone can go and fill a few blocks for cheap, but to sustain that for longer periods won’t work.
Full nodes and validators have to be sized to handle sustained full blocks anyways, so I don’t think the gas minimal has any relation to the resource commitment that operators have. (e.g. you need good enough CPU and storage to handle peak congestion regardless, so your machines are sized to that even if the network is mostly idle).
As for raising the gas minimal to 0.1 cent per ERC20 transfer, I don’t think ERC20 transfer is a good gauge of onchain activity. Nobody actually just does transfers onchain, it’s always interacting with smart contracts like Uniswap or other protocols, and protocols carry higher gas consumption than vanilla transfer.
I think it would actually be quite difficult to make gas pricing depending on the tx content, because not all transactions are transfers. And if we want to avoid people spamming the network, then we could actually make the problem worse: instead of sending one $100 transfer, people is now incentivized to make two transfers of $50. And it gets worse for bigger transfers.
Thanks a lot to those who have made the points about micropayments on Celo.
I do think though, that allowing transfers of cents off chain is actually counter productive giving the current limitations on gas limit by a block. If we fill blocks with 10 cent transaction, that means that if the network has a total capacity of 1000 tx per block, that means that transfer capacity of a block gets reduced to just $100, which I don’t think is an outcome anybody would want.
Maybe there’s a way to process smaller payments without the gas hit, like using channels similar to LN and just settle them on chain? Or having users accumulate balances and then settle when they are willing to pay the gas?
And also keep in mind, as Tim said, I consider rallying a product on negligible gas prices is not the right way to go, as a spike in network demand for blockspace could come right now.
hey @kalatsong, we have already started to work on an implementation proposal - it’s not super complicated from the eng side, however, as changes in the core contracts need to be audited, the timeline is still a bit unclear… talking couple of months till final proposal ready
I am kinda confused by this proposal and it’s goals.
Assuming long term goal is for Celo usage to increase to levels where blocks are decently full on a regular basis, no matter what the tx costs are, full nodes and validators will have to handle those loads anyways.
Keeping TX costs very low keeps volume high today even if larger percentage of these txes aren’t super necessary. This makes network more ready to actually handle larger real tx loads in the future.
Imo, if you increase TX costs artificially right now , you will reduce TX load but that seems counter productive because now you can no longer test the network actively with larger loads that we hope we get to in the future .
And once/if network usage actually increases, tx price will be determined by market anyways.
Imo, I don’t see any positives that this change can bring and can see quite a lot of downsides. Tbh none of the arguments for its support make any real sense to me
From my perspective, layer 1s are in the business of selling “block space” and we (CELO holders) can’t give away our “product” for free and sustainably cover expenses, like validator fees, in the long-term. If throughput continues to increase through scaling efforts, transaction fees could remain infinitesimally small. If we make transaction fees small but manageable (fraction of a penny), we can increase “revenue” used to buy back CELO through EIP-1559 burns to cover costs while keeping the blockchain usable/attractive for applications built on Celo (in addition to potential DDoS risk reduction benefits).