Gas Limit Discussion

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.

Addendum

This post will bring readers up to speed on the current Gas Limit discussion happening in Ethereum Classic community.

On 2024-03-19 a call involving ETC contributors and core developers was recorded.

https://www.youtube.com/watch?v=8poOPwNCCeg

Notes for that call were also prepared.

https://github.com/ethereumclassic/community-calls/blob/main/20240319_038.md#ronins-position-from-discord

A summary of the call and raw transcript is available near the end of this document.

In short, the main debate could be summarized as: Bloat vs Utility.

Bloat - a major concern for maintaining long term decentralization. Large blocks will over time increase physical requirements for syncing thus reducing the number of nodes that can sync. See blocksize wars and call notes.

Utility - for developers, the ability to make higher gas transactions makes it easier to deploy to ETC. While not a major problem currently, a low gas limit could present friction for developer adoption. If left completely unaddressed, it may cause ETC to become unsuitable for some Smart Contract developments in future. While gas limits are in most cases workaroundable, this may require additional developer time to “port” things to ETC, which makes deployment less likely with budget constraints. This in itself creates friction to developers and avoid ETC as they’d need to spend time to check whether or not their contracts are compatible.

The “traditional” mechanism to resolve this conflict is allowing miners to raise or lower the block gas limit, which crudely trades off Bloat for Utility or vice-versa. Originally this system was designed to increase the limit for the purpose of allowing more transactions (lowering fees), but it has been proposed to use it to enable high gas transactions.

This mechanism was likely not designed as a solution for low bloat with occasional high value transactions. It was proposed that alternative options may exist that solve both Bloat and Utility concerns by allowing limited high gas transactions while maintaining low chain growth.

No recommendation for immediate action was made during the call, but it was agreed that the topic deserves further research and discussion.

Next Considerations

Following the call, some additional questions arise that must be researched to tie up loose ends before consensus is reached. Participants are encouraged to consider the following questions as the discussion continues.

How necessary is allowing high gas transactions?

Existing real world high gas (30M) transactions are rare. As such, there is presently not much pressure to increase the limit and it is not a huge limiting factor as almost all contracts deployable on ETH are currently also deployable on ETC.

However, in the future, ETH’s 30M limit is likely to encourage developers to target higher gas contracts, so we can expect this to be a limiting factor for deploying contracts to ETC in the future.

Furthermore, enabling high gas transactions may be an opportunity (a la Thanos) for ETC to provide a quantitative advantage to developers over Ethereum; allowing very high gas (30M+, eg 100M) transactions could be a Unique Selling Point for ETC.

Allowing very high gas transactions would allow for otherwise undeployable complex (or poorly optimized) contracts to be deployed, and allows large L2 blob proofs to be committed to the chain. This could make ETC the only option for some applications.

So, how pressing is it to actually take action to change the limit?

Should we take a “wait and see” approach, or be proactive?

What hardware do we want to target?

Should ETC target increasingly capable hardware as time goes on?

What are the minimal hardware specs we should target today and going forward, assuming worst case bloat scenario?

Assumptions about future hardware is difficult and we cannot guarantee that it will always be easier to sync, it may in fact get harder in the case of societal disruption.

What will be the long term effect of various gas limits?

We can deterministically model various different gas limits to determine long term best and worst case scenarios for the chain and hardware requirements in the future. This research would enable better decision making about bloat concerns.

Does having large transactions introduce other problems?

Bloat is the main issue we want to avoid to improve long term decentralization, but let’s make sure we don’t introduce other issues if we accept large transactions of 30m+

What are the constraints in terms of computation of large transactions? Can nodes still manage occasional 30m, 100m or even 999m blocks and still keep in sync on the hardware we want to target?

How to signal to miners?

If there’s consensus to change the gas limit via miner vote, how should we formalize signalling to miners?

It’s difficult for miners, who may not be tuned into the community, to judge whether social signals are real or astroturfed.

In the case of emergencies, such as raising from 1M to 8M, an ECIP might be too slow, but not so slow, and it helps miners understand. Perhaps we should use it in future.

Is ECIP a suitable process for signalling?

Does this give ECIP editors too much control?

Could we develop some other signalling process?

What happens to > Gas Limit txs in the mempool?

Chris mentioned on the call that perhaps TX v2 would allow larger than gas limit transactions do be mined.

Istora: I do not believe this is the case as such blocks would be invalid. However, whether or not such transactions remain in the mempool might make integration of a solution easier. I guess they are just rejected, but client code could be updated to allow them and only mine them when they are able to (such as a N%100 block).

Does Danksharding change anything?

Given darksharding seems to be part of the Ethereum future, is there anything we need to consider before implementing a gas limit change, or perhaps advantages that can be taken if we do make a change.

https://www.galaxy.com/insights/research/protodanksharding-what-it-is-and-how-it-works/

Potential Paths Forward

To help understand the idea space, some potential options are laid out below for participants to consider. Istora provides a brief opinion on each option.

Do Nothing

Simple. Easy. Default option.

If there’s no need to change or fix the limit, then why go to the trouble?

However, we miss out on potential advantages and don’t address concerns raised during this discussion.

In any case, we can probably do nothing (even for a few years if needed), and take our time to draw the best conclusion.

Socially signal to have miners increase the limit to ~15m

The seemingly most agreed upon ‘quick fix’, but is it really necessary?

Especially for ETC, the current voting mechanism does have draw backs as how miners are signaled creates a centralization issue.

If we maintain the voting mechanism, we should probably figure out a process for formalizing this signalling after reaching consensus, otherwise we risk creating new power structures and controversy about decision making.

How do they know who to listen to, does ETC coop get to decide, do astroturfed twitter bots?

Socially signal to have miners increase the limit to ~30m

Similar to above, but more dangerous, as flagged by core devs on the call.

Difficult to find consensus due to bloat concerns.

Fix the Block Gas Limit to something like ~15m

A good solution to reduce power of miners to change the gas limit.

Should address concerns raised by core devs on the call.

Requires a hard fork

Fix the Block Gas Limit Delta

Similar to above, but set a fixed and linearly increasing block gas limit over time to target improved future hardware.

Requires a hard fork

Wiggle Room

To prevent miners from reducing the limit too low (e.g. 1M), limits could be set for a minimum and maximum block size target for miners.

Has the advantage of being able to be implemented without a hard fork by having hard or soft limits within the clients without a protocol change.

Generally agreed upon as a reasonable middle ground, but doesn’t really address the Utility problem or future large transactions.

Does not address the social signal issues raised above.

What should the window be - 4m to 40m ?

One Large Block every N Blocks

Voting mechanism removal not withstanding, a simple fix to enable large transactions would be to allow one block every N blocks to be 10x the base block size.

If the gas limit is 10M, then every 100 blocks, a 100M gas block could be allowed for larger transactions. Assuming that large transactions remain in the mempool, they’d just need to wait (and provide a large gas fee), to be included.

Simple, but seems kind of janky?

Does this mess with block explorers?

Requires a hard fork

Long Blocks

Proposed by phyro, we could increase the block time to 60 seconds per block and increase the gas limit per block accordingly, allowing for larger TXs to get through without changing bloat.

Would need to adjust block reward to keep monetary policy accordingly.

Would change a number of assumptions in the rest of the ecosystem wrt confirmation times.

Simple.

Main downside is user experience when interacting with ETC; transaction confrimations would take 2+ minutes instead of 30 seconds.

Requires a hard fork

Native Gas Token

Inspired by the notorious https://github.com/projectchicago/gastoken, which was the cause of much bloat on ETC, the protocol could implement a native gas token that does not waste gas but allows it to be ‘mined’ and credited for use in later blocks.

Bloat remains the same but the token could be minted by developers who wish to make large transactions.

• A token that can be auctioned off
• No more than 10% of each block’s gas (?). Fees go to miners.
• The auctioned gas 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 dissolves 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.

Because of it’s complexity and poor Developer Experience, I think we could do better if we wanted to achieve high gas transactions.

Requires a hard fork

Cody’s “Elastic Block Gas” Proposal

Requires a hard fork

AI Summary

Cody proposes the implementation of an “elastic gas limit” for Ethereum Classic, aimed at optimizing block gas limits based on network utilization. This concept involves adjusting the block gas limit dynamically, guided by an exponential moving average (EMA) of past blockchain usage. The proposal suggests that if a block’s gas usage deviates significantly from the EMA, the block reward should be reduced exponentially to encourage miners to adhere to the optimal gas limit. The idea is to create a self-regulating system where miners are incentivized to produce blocks with gas usage that aligns with the community-defined optimal utilization, ensuring stability and preventing node bloat due to arbitrarily large gas limits.

Isaac raises a concern regarding the potential contradiction in the system, particularly about offsetting low transaction fees with block rewards while also penalizing miners for producing empty or low-value blocks. He questions the objectivity of measuring block emptiness and the implications of relying on transaction availability as a metric, hinting at the complexity and potential challenges in enforcing such a system without unintended consequences.

Ronin likes the elastic block limit proposal, highlighting its potential to maintain a relevant and stable L1 fee market across different market conditions. He notes that the mechanism could prevent fee spikes during high congestion and adjust blockchain size in response to varying network activity, ensuring that miners remain incentivized. Ronin also appreciates the transparency and logic of the proposed system, drawing parallels to the dynamic difficulty adjustment for block times. He suggests that this approach could make the blockchain more efficient and responsive to actual usage, eliminating arbitrary gas limits and better accommodating special data needs, such as L2 rollups and complex contract deployments, thereby enhancing overall network scalability and stability.

Full discussion on Discord

https://discord.com/channels/223674353001168906/223675625334898688

DontPanicBurns — 19/03/2024 21:46 My unfinished notes on elastic block gas: https://gist.github.com/realcodywburns/01a2af8fb4dd8a5bc51089af2036c2a4 Im still consolidating into a readable format, these are the punchlines

isaac — 19/03/2024 23:50

is there a game contradiction between offsetting/subsidizing low tx fees with block rewards, and deterring empty blocks? we can only judge (potentially faked) block emptiness using tx availability, which isn’t objective

if a miner produces empty or low value blocks, they will forfit their block rewards ... The current block reward should be viewed as offsetting the fee market

DontPanicBurns — 20/03/2024 00:25 our block reward reduction was somewhat arbitrarily picked. is a nice round number, it doesn’t relate to any onchain metrics. I see it as offsetting the fee market because i think that miners operate on a slim margin and they compete based on how cheaply their cost of electricity is. If this is true, a reduction in block reward equates to a reduction in thier income and network security. In the future when there is no block reward, transaction fees will need to provide at least the same level of income as the current block reward to ensure the same level of security. empty blocks and blocks that have significantly less transactions than average are a nuisance. empty blocks are marginally easier to mine since they require no tx verification, so a miner can use a fake time stamp and start solving as soon as they have a valid block. These are both transient problems that go away as the network gains adoption. on average, all blocks should use an average amount of gas in a health network. I dont think we can guess a magic number and i do not think having completely full blocks are desirable if we want actual usage. miners should strive to add as many transactions as possible, if it isnt possible they would get a slight penalty. so i think that the average block gas used should roughly equal the current block reward to ensure the equal level of security i mean tbh its a limit so its more of a safety measure to prevent spam. currently blocks are not near the limit so it is only relevant because sometimes contracts want to deploy big contracts. it isn’t as if setting the limit at 100m would require blocks to use that much. the hazard is in that the limit is randomly set by miners rather than tied to something

ronin — 21/03/2024 00:06 I really like the logic in this document Cody. I see so many benefits to the elastic block logic. L1 Fee market immediately becomes relevant and STAYS relevant. Also prevents the huge fee spikes we see on ETH when the network becomes too expensive to use due to congestion events and the fixed gas limit. In bear markets when the network is processing less, the fees will remain reasonable by the block size increasing. In bull cycles when usage is up, the fees will remain reasonable by the block size increasing. This helps accurately price the blockchain space through the life of the network, rather than the current arbitrary limits in place. It also codes in miner fee incentive logic, thus removing the for miners to coordinate to make the fee market relevant for them.

Coding this logic makes it very transparent on how the gas limit will adjust. And it is a very similar approach to the logic around a dynamic difficulty to maintain 14 sec block times and variable hashrate.

Common daily data: Elastic blockchain space for calldata to keep bloat under control and relevant to actual common daily usage. This would make the L1 fee market lucrative always for the miner ecosystem. Makes it so the fee market becomes effective once implemented and our security budget is not only the ETC coin emission. This also helps with the imminent L1 scaling issues as the elastic block space will grow with higher demand and prevent the huge long term fee spikes on L1 as witnessed on ETH due to their hard capped upper limit. Also removes the arbitrary subjectivity of the gas limit as highlighted on the call by Donald.

special data: special designations for scaling data like L2 blobs and functionality data like large complex contracts for L1 deployment. The L2 blobs in the Dencun upgrade being a model for how to handle specialty data that may be restricted by the elastic gas limit, but is very favorable to the L1 EVM because it adds utility/functionality/scalability.

So where in our difficulty logic, the constant is that we want a soft-peg to around 14 second block times. Here we want a gas limit that adjusted to a reasonable fee market price (demand). Does that make sense?

Then if we look at how Dencun is handling L2 data differently in these BLOBs, we now have an avenue to address the transactions that are less common day L1 transactions and more dynamic, like a rollup scaling transaction, a complex contract deployment, or a reoccurring infrastructure transactions like a public good price feed (just an example) that maintains stability in the Dapp enivronment and tethers on-chain logic to off-chain logic.

Elastic Gas Usage

Requires a hard fork

Perhaps we can come up with another optimal solution that combines Cody’s dynamic block size with the ability to have large transactions. Further research into such a system would be required. Watch this space.

Istora — 20/03/2024 20:36 @DontPanicBurns your system seems to be targetting average block limit, but could we instead target overall gas usage? might be misunderstanding your notes, but if we could enable otherwise empty blocks to allow for 5x block limit transactions, it’s same same, right? so the block limit is replaced by your EMA, but a rolling gas allowance instead of block limit this is to address ronin and other dev concerns, enabling huge TXs and providing massive value as a complex tx and L2 blob repository, but still keeping bloat algorithmically controlled

(reply) DontPanicBurns — 21/03/2024 07:16 yes actual gas usage makes the most sense. it will make it costly to game the system

Other Research Links

https://www.cryptoeq.io/articles/ethereum-gas-increase https://www.coindesk.com/markets/2018/01/18/blockchain-bloat-how-ethereum-is-tackling-storage-issues/

Transcription Summary

Donald

• The main problem is bloat
• There’s no perfect block size, but it’s important for it to remain small
• Miners being able to change the block size is risky
• The gas limit should be fixed between 8M and 15M
• Take away the power from miners to change the gas limit - no group should have arbitrary power to change this
• The protocol fixing of gas limit makes it impossible to change the limit without a hard fork

Istora

• Strongly agree with the above points with regards to bloat - maintaining low chain growth is a high priority.
• Raised the issue that a fixed block limit in bitcoin caused a chain split (BCH), whereas the ETC miner voting mechanism avoids such outcomes.

Donald

• It’s important not to think in the traditional “visa” mindset where “more transactions is good”. Instead, focus on the core cypherpunk values of decentralization.
• Big block chains, like POS is broken; it’s centralized at scale.

Istora

• One more problem with increasing the limit is that the protocol is not ossified and it creates capture. Politically, it opens the door to future increases due to precedent. A chain split will divide the community and centralize decision making to cliques that made that decision to fork.

Diego

• The comparison between BTC and ETC isn’t totally fair
• In ETC, gas is used for computation, which is more complex than BTC UTXOs
• In the past, the ability for miners to reduce the block size has been useful as a means of protection, such as exploits or misprised opcodes, that were exploited to create full blocks very cheaply. Miners were able to temporarily reduce the limit while a fix was implemented.
• This proces is far faster than coordinating a new release via hard fork (weeks vs hours).
• We can increase the gas limit to around 15M, should’t be a problem technically.
• Not a good idea to change the miner voting mechanism.
• We are still in the development stage, but eventually we want to ossify the protocol so developers do not need to make changes, so the miner voting mechanism allows the limit to change without developers updating the protocol, which is an advantage.

Istora

• Agree that current mechanism is good
• We don’t know future transaction types or vulnerabilities that may require higher or lower limits
• The current mechanism allows us to mediate that process without causing a hard fork and potential chain split

Istora (reading Ronin’s notes)

• Reads https://github.com/ethereumclassic/community-calls/blob/main/20240319_038.md#ronins-position-from-discord

Ronin joins the call

Ronin

• Don’t have the solution, but looking at the gas limit as a problem from the perspective of an “on the ground” developer, and talking to other developer teams
• Maintaining EVM interoperability is the main concern
• Developers will target 30M as the default, which is industry norm
• Lower limit creates friction
• Get ETC up to date to 2024 standards if we want 2024 applications
• Fixing the gas limit is a much more complex conversation
• The current approach of allowing miners to change the limit to whatever they want is “kicking the can” long term
• Not just contract deployments, but also complex transactions

Istora

• Agree with both Ronin and Donald’s concerns.
• Requiring developers to rewrite code to deploy is a massive loss for the utility of ETC.
• Limits L2 technology if large proofs can’t be published.
• Increasing the block gas limit is a very blunt solution.
• A better solution would be to keep the overall gas usage low/limit, but still allow for high gas transactions - separate these concerns to address both concerns.
• Proposes “gas credit” or “native gas token” system where gas can be purchased and redeemed at a later block to allow for a more complex contract.
• In this system, bloat does not increase, but large transactions can be made.
• This is a complex solution (both protocol and end-user), not ideal. ed: I now think a more elegant solution riffing on Code’s Elastic Block Limit is possible, see below

Ronin

• Agree that we don’t necessarily want the 30M gas limit on all transactions all the time. It’s unnecessary for most blocks to have a high limit.
• Just having one big block (e.g. at the start of each month) would allow complex transactions to be performed, which would give devs the opportunity to deploy.
• We simply don’t want to have devs to put in custom engineering time and cost associated to deploy contracts.
• Developer teams are immediately hesitant to think about ETC when they hear “8M gas limit”, substantially lower then 30M, as they’ll need to check all their code before thinking about deploying.
• This creates friction, even if devs don’t need to change their code at all.
• “Anything on ETH can be deployed to ETC” is a lie because of the 8M gas limit.

Istora

• There’s a potential opportunity for ETC to get an edge of Ethereum Mainnet by allowing higher than ETH Gas Limit transactions.
• If there’s a higher TX limit, you’ll have projects that aren’t optimised and can’t deploy to ETH will deploy to ETC instead.

Chris

• Not against changing the gas limit, but requires research
• Requested more details about the contracts that can’t be deployed
• On ETH, the main reason they increased the limit was for TX throughput (lower TX fees), not just for individual large transations
• Do not like the fixed gas limit idea, it creates new problems
• Open to a “wiggle room” option, where a fixed window eg 8M to 20M that miners can vote on
• Agrees with bloat concerns being a priority
• You may be able to currently do a transaction that is higher than the gas limit with TX v2 - if this is true, then miners might be able to change accept it

Diego

• Ethereum Mainnet has https://eips.ethereum.org/EIPS/eip-1559 enabled
• Therefore the “target” limit on ETH is half-full blocks, so, in practice 15M. 30M is the upper limit, but 1559 tries balance throughput and bloat.
• We are researching whether 1559 is compatible with ETC. 1559 burns the base fee, so would need to be modified to work with ETC’s fixed monetary policy.

Ronin

• Rollups / L2 Settlement is important
• Proto Danksharding should be considered
• Let’s not rush into a solution

Istora

• Agree we shouldn’t rush, this is just a first step of exploring options
• Looking forward to Cody’s proposal (see below)
• We have time to find a solution that has the best tradeoffs available.
• A simple increase in block size doesn’t seem to address both concerns.

Ronin

• Arbitrary limits and fixing things with a hard rule will create future problems and set a bad precedent
• Dynamic approach is better when possible
• Acknowledges the importance of reducing bloat, and likes istora’s idea of having large txs with low bloat

Donald

• Reiterate bloat concern, physical restrictions
• Also, we need to limit humans making subjective decisions about block size

Istroa, interrupting

• Disagrees that the current mechanism is more subjective
• Miners voting with their hash rate is just as subjective as the current longest chain rule

Donald

• There’s a group of humans deciding the limit, but yes they do it within the constraints of the protocol
• Agrees with diego that it may be useful to allow miners to change the limit
• Agree with ronin that we don’t know the perfect blocks size or future optimal requirements; we have these uncertenties
• Also agree with ronin that reducing friction for developers and interop is important
• Maybe fixing the gas limit may bring new problems, but perhaps “wiggle room” is better
• Do not have a strong opinion yet

Ronin

• Yes, it’s good we’re all open minded
• We don’t want humans to be able to arbitrarily change the limit
• It’s not a good model for the long term for miners to be able to change the limit

Istora

• Requiring miners to hard fork to change the gas limit does create a barrier but doesn’t create a fundamental change in terms of balance of power
• If miners wanted to coordinate, they could just tweak the gas limit and mine that chain - it’s still fundamentally within their control
• The current mechanism just allows them to come to an agreement on what the gas limit should be without risking a chain split

Donald

• There’s no equivalence of changing the gas limit (like they did last year)
• One mining pool with 30% of the hash rate can change limit down to 1M
• The threat of a split dissuades miners from changing the limit

Chris

• When the miner was able to change the limit (to 1M), they had more than 30% of the hashrate
• One option can set a “soft floor” minimum in the client, which will warn miners if they change to a crazy limit, this does not need a consensus change
• The 1M change was probably just because they didn’t know what would happen

Istora

• My theory is that there was some mining software update that was misconfigured default that set the limit to 1M, and miners blindingly ran this without intentionally changing the limit

Chris

• Indeed

Ronin and chris discuss current gas limit defaults on clients and testnet

Istora

• What caused the 1M change is tangental to the main discussion
• I’ll compile notes on this call

Donald

• To clarfiy, the current 8M limit is just the default, the miners could change to 30M in a few days if they wanted to
• If devs really wanted 30M tx, they could appeal to miners on social media and have them raise the limit

Ronin

• Most old contracts don’t hit the limit, but some of the new ones do

Chris

• Most new contracts developed today will be dealing with L2, but ETC doesn’t have L2 yet
• Developers should signal to ETC that they want to make use of it before we raise it

Donald

• It would be great if we could have small blocks most of the time but allow developers to occasionally make big transactions. It would be great if the protocol could allow this. Istora mentioned this.
• I don’t think it’s possible right now.

Istora

• Yeah, it would require a Hard Fork
• The simplest thing would be, for example, to have 1 big block every 100 blocks or so
• It would be better to have a more dynamic system where you only get the big block when it’s needed
• Both require a hard fork

Everyone

• Great to have the call, thanks for joining
• This is a great way forward for the protocol