20240319_038.md

description	date	time	location
Gas Limit Discussion	2024-03-19	1200 UTC	ETC Discord

Addendum: https://github.com/ethereumclassic/community-calls/blob/main/20240319_038_addendum.md

Let's talk about Block Gas Limits on Tuesday 19th March 2024 at 1200 UTC.

The voice chat is an open discussion and anyone is free to join and contribute.

Join the call in ETC Discord's #community-calls channel.

The call will be recorded and uploaded to YouTube.

This will be quite technical, so do feel free to jump in at any time to ask questions or request clarification.

---

This call was prompted due to discussion on Discord about what to do about the Block Gas Limit.

The Block Gas Limit is the maximum amount of gas that can be used in a block. As such, it also limits the largest transaction size per block. This includes contract deployments, but complex contract deployments can be split into multiple transactions.

The debate was triggered by the recent (last year) 1m gas limit that was inexplicably(?) voted on by miners, which caused isuses for devs deploying contracts. This was corrected back to 8m after coordination with miners.

Miners are able to vote on a target block gas limit. Over time it adjusts. There's no upper limit, lower limit is 125,000.

Block Gas Limit is notorioulsy tricky to get right, a small limit means fewer/less complex transactions can be made, and too big means that chain bloat can be a problem (which centralizes things).

The Debate

Four participants have put some views forward in Discord and may be joining the call, which have their own positions. Donald, Ronin, istora, Cody.

In their own words explain their position, if not I will attempt to explain.

Doland's position

1. To fix gas limit between 8 MM and 15 MM.
2. That miners or no one should not have discretion to change it.
3. That following what ETH does may be risky because they don't care about "Code Is Law" but they do everything by "Social Consensus"
4. It is more important to fix the block size and make it very difficult to change again so that blocks remain small.
5. Developers should adpat to the gas limit, not the other way around. What ETH does is very irresponsible.

Ronin's position (from Discord)

Observed: 8M gas limit is a drastic restriction for the 2024 application development standards. Currently most development teams are operating around a 30M gas limit. Therefore the 8M gas limit is restricting the smart contracts that can be deployed to Ethereum Classic. Leaving it at a disadvantage to other EVM networks like ETH Foundation, which is the EVM ETC aims to maintain protocol parity with to remain state-of-the-art.

Protocol Parity logic states that we are trying to provide a similar development environment with ETH Foundation for dapp development. In the application environment, we have minimal differences. Notable are EIP-1559 that was excluded due to its impact on the fixed monetary supply (ECIP-1017). However, we have a voluntary difference of 8M gas limit (ETC) vs 30M gas limit (ETH). This restricts the size of smart contracts that can be deployed on the network. The current EVM application ecosystem is developing around a 30M gas limit. If the goal is for applications on ETH to easily migrate to ETC due to protocol parity. It's logical for the gas limit to be the same. Difference effects: contract size, reoccurring calls, & deployment scripts. more?

How to adjust: Current method is social consensus, then alerting the mining ecosystem. Change does not require a hard fork, is merely social. Likely needs to be documented/justified in the ECIP process. Once changed, should take ~2 days for gas limit to rise from 8M to 30M.

Rationale: this allows the application layer to grow and support more complex contracts like advanced lending/borrowing protocols. Allows 2024 state-of-the-art applications to be deployed to ETC. This should help to produce a lucrative fee market for miners to earn more than the chain emissions. Also this should allow ETC to easily gain intellectual/human capital in the bare application space. Enables chain agnostic EVM development with the largest application layer EVM community. A big upside.

Istora's position

Both Donand and Ronin's positions have merit.

I appreciate having a low gas limit: used to support in theory a 1m gas limit, which I realize is not practical.

At the same time it would be beneficial if devlopers can publish their contracts with ease, and if there are valuable contract systems being used that use 15m + gas, this limits ETC's usefulness if devs have to workaround this limitation and re-write ETH contracts. It may also limit future L2 tech if proof publishing is limited.

However, increasing every block's gas limit to allow for the occasional mega-complex transactions seems to be suboptimal, as it encourages bloat, and most blocks will be unintentionally full of small TXs.

Generally I reckon if it ain't broken then don't fix it, so right now I currently support the current state of affairs, but would be open to encouraging miners to vote on gas limit.

The gas voting mechanism is a pretty good solution (agree, not perfect) because it avoids hard forks to change the limit and thus reduces chain split potential. We don't know future hardware advancements or transaction types. Having a way for miners to adjust without forking provides value. Miners control the limit if it's fixed anyway (through hard forking). Donald, let's discuss, esp. Code is Law.

I also welcome disucssion on my Native Gas Token idea (could allow us to lower the limit), which I think satisfies both Ronin and Donald's concerns.

Cody's position

"i have a rough draft of my elastic gas limit idea"

Clearning Things Up

Let's step through the logic of the debate and ensure we're all on the same page.

Point A PRO or AGAINST Setting a High Gas Limit

Which can be achieved independently in a number of ways;

Point B PRO or AGAINST Changing the Gas Voting Mechanism

Such as:

• Encourage Miners to change the limit (against changing the mechanism)

OR

• Fix the gas limit in the protocol layer (removing the voting mechanism)
• Implement an "alternative option" (discussed below)

Point A: AGAINST Increase

See the Bitcoin "Blocksize" debate. Effectively the same, but with some nuance for ETC. Essentially, the greater the block gas limit, the greater the hardware requirements to participate, the fewer participants, the more centralized the network becomes.

Arguing to absurdity - suppose there was a 100,000m block size with full blocks. In this case, nobody would be able to sync on commercial hardware as the hardware requirements to do so would be huge.

Point A: PRO Increase

Bitcoin and ETC have different reqruirements in this regard.

Deploying and executing complex smart contracts. See Ronin's explanation above.

Another thing to consider that may reduce transaction fees, but if there are full blocks, the effect will be marginal and high fees are a feature of popular networks. ED Istora: IMO, lower fees should not be an argument in this debate.

Point B: AGAINST Mechanism Change

• Requires a Hard Fork
• Other than a Fixed limit, adds complexity

Point B: PRO Mechanism Change

• May be possible to find a solution with better tradeoffs than simple solutions
• Potentially upgrades functionality and value of network without requiring

Alternative Options

Increasing gas limit over time, like the emission curve

A fixed (linear) increase in the upper/lower block gas limit to try to cater to increased hardware availability in the future to increase scalability marginally.

• This could be fully fixed similar to Donald's proposal
• Or it could increase the upper/lower bounds that could be voted on by miners

Pros: Simple Cons: Arbitrary, and assumes that hardware capabilities will increase (what if there's a Chip War that stalls development, or a dark age)

Dynamic Gas Limit (Cody)

TODO

Native Gas Token (Istora)

• A token that can be auctioned off
• No more than 10% of each block's gas (?). Fees go to miners.
• The auctioned is "used" but does not contain much data, so doesn't contribute to bloat, reduces the chain growth for that block.
• 1 token = 1 gas credit
• Once minted, this token disappears after N blocks (so it is not hoarded indefinitely).
• The token can be accumulated by developer and then burned in exchange for extra gas when they make a complex transaction (even more than 30M!).
• The result is that net chain growth is the same (or less), while still allowing developers to make complex transactions / deployments.
• Combine this with fixed block limit, makes Ronin and Donald both satisfied.
• Comes at the cost complexity and economic considerations; significant protocol change.
• Token logic implemented in smart contract layer.

Things we can do

Simulate various scenarios for future gas limits and usage and hardware requirements (can probably find in ETH land)

Continue the disucssion

---

Post chat notes

ronin

I cited curvance.com as an example of a newer 2024 set of contracts that is struggling to get under 30M gas limit on ETH mainnet gas limits. I think large contracts like this are not the norm, but may become the norm in 2024 and onward.

I also cited LayerZero bridge as an example of an infrastructure integration that is concerned about 8M gas limit. This may not be due to their specific contract sizes, but their deployment scripts/reoccurring multicalls for data form 30M assumption to 8M gas of data. So think of the added engineering costs to rewrite a custom ETC deployment script/adjust 30M reoccurring transactions from 30M logic to 8M logic. This is a more common friction I am seeing, opposed to large contracts.