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.
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.
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.
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?
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.
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.
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?
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?
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).
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/
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.
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.
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?
Similar to above, but more dangerous, as flagged by core devs on the call.
Difficult to find consensus due to bloat concerns.
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
Similar to above, but set a fixed and linearly increasing block gas limit over time to target improved future hardware.
Requires a hard fork
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 ?
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
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
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
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 blockchain size would adjust down to keep miners earning fees. 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.
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
https://www.cryptoeq.io/articles/ethereum-gas-increase https://www.coindesk.com/markets/2018/01/18/blockchain-bloat-how-ethereum-is-tackling-storage-issues/
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)
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
AI transcript generated from YouTube
Lo welcome to ather classic Community call today is the 19th of March
0:13
2024 today we're going to be talking about the ethereum classic block gas
0:19
limit uh we're currently in the ETC Discord Channel but this will be uploaded to
0:25
YouTube it'll be quite a technical conversation so do feel free to jump in at any time and ask questions or request
0:31
clarification or make any comment this call was prompted due to
0:37
discussion on Discord about what to do about the block gas limit on ethereum classic the block gas limit is the
0:44
maximum amount of gas that can be used in a block as such it also limits the largest transaction size per block this
0:49
includes contract deployments but contracts but complex contract deployments can also be split into
0:55
multiple transactions the debate the debate was triggered by the recent last year 1
1:01
million gas limit that was inexplicably voted on by miners which caused issues for devs deploying contracts this was
1:09
eventually corrected back to 8 million after coordination with
1:15
miners miners are able to vote on the target block gas limit over time it
1:21
adjusts there's no upper limit and the lower limit is 125,000 block gas limit is notoriously
1:27
tricky to get right as a small limit means that fewer and less complex contracts cont transactions can be made
1:35
and too big means that chain blow can be a problem which in turn causes
1:43
centralization so the debate involves on Discord four participants who have put
1:49
some views forward and hopefully will be joining the call and uh expressing their
1:54
positions this includes Donald McIntyre who's joining us today Ronin who will
2:00
hopefully join us myself and Cody Burns who also mentioned he might be able to
2:06
join in their own worlds they can explain their position and if not I'll try to do so on their behalf so first
2:14
would you like to take the stand on to explain your proposal for I believe
2:19
fixing the gas limit yes thank you istor and thank you
2:25
for the introduction um as a president the gas limit debate it's important to
2:35
note that in Bitcoin in in between 2015 and 2017 there was a
2:42
very very serious um debate and and they
2:48
call it the war the block size War um that was precisely about this it it was
2:57
it was about the size of each block Bitcoin historically started I think
3:03
with no set size then they discovered a bug at some
3:10
some point in the history of of Bitcoin and Satoshi Nakamoto decided
3:16
to um give each block a specific size of one
3:22
megabyte and at the time I think his explanation was to prevent
3:28
spam um and let's see what happens in the future and we're going to solve whatever happens
3:34
in um by by by 2015
3:39
2017 Bitcoin was much more popular everywhere in the world people
3:45
were using it and people started to say okay if we keep the small block of one
3:50
megabyte it only fits uh x amount of transactions I think
3:55
it was like 250,000 transactions uh per block um we we're going to not going to be
4:04
able to compete with visa for example that that uh they process billions of
4:09
transactions per hour or per day we're going to we we're only going to uh
4:16
process 20 sorry 250,000 per day um it
4:21
was it was around 2,000 per block something like that
4:26
um but there was a group of of of so so they were saying we we need to
4:32
increase the block size to 10ab 20 megabytes 30 megabytes and like that
4:38
time passes by but there was a a group of maximalists who said no this this the
4:44
increase in the block size basically makes the blockchain bigger the database bigger and in Time new people who will
4:52
want to will want to run noes uh are going to find it impossible to download
4:59
Lo the software and then synchronize with the network because it's going to be so big in terms of gigabytes of
5:05
information or terabytes of information in the future that um to be impossible
5:11
for new people to join from especially from places with low bandwidth all
5:17
bandwidths in other parts of the world and in the
5:23
end the the Bitcoin is going to centralize into a few big nodes in the
5:30
in the developed world where there's high band internet bandwidth and they have they have powerful Computing
5:37
resources compute all the new blocks and also to to create new notes and things
5:43
like that uh and we're going to go back to the centralized model of banking and
5:48
all that the same this same Theory applies in eum classic ethereum classic
5:56
if if the blocks of ethereum classic which are every 13 seconds rather than every 10
6:01
minute um get bigger and bigger and bigger uh than um the problem of
6:08
bloating bloating is this problem of the size of the of the blocks and that
6:15
impacts the size of the the database itself which is going to make it practically impossible in the future for
6:22
people to synchronize a new node and it's going to reduce number of nodes in the network it's going to reduce also
6:30
the the coverage in regions and things like that because of bandwidth because of local computing power and things like
6:36
that so the the the however in in in ethereum ethereum
6:43
and Etc were one network at the beginning I I am doing this like basic
6:49
introduction Cas there's listeners who who don't know the background so
6:54
ethereum and ethereum classic were the same blockchain in in the beginning and
6:59
and for some decision umal at the time they said okay we don't
7:05
know what is the the the perfect block size and that applies also with bco really there's no there's no perfect
7:13
block sizei Nakamoto just said one megabyte then it was modified with
7:19
something called segwit that now it supports two two megabytes per block
7:26
there was after that war in 2017 there was a modific ification of the of the block size um that increased it from 1
7:34
Megabyte capacity to 2 megabyte Capac it's it's a it's a technical
7:40
thing it remain the the important information is that it remained small
7:46
and the small blockers won that war so that's a good precedent in in Bitcoin
7:52
and it's a conservative way of managing the blockchain but in in the case of ethereum for some rationale at the time
7:59
when it was design between 2013 and 2014 they decided that there was was not
8:04
going to be a fixed or set size like in Bitcoin and that miners would decide the
8:10
block size depending on the demand of block space the volume of transactions that had to be handled the volume of new
8:17
smart contracts or executions and that um so the model of of Etc remained like
8:25
that um when when Etc and ethereum split in 2016 so now Etc is an independent
8:32
chain then ethereum move to proof of stake um so they have a whole new set of
8:38
problems there and it's a centralized system so so that that doesn't concern
8:44
Etc anymore for the purposes of this of this topic but Etc remained with this
8:51
model where the miners basically decide the block size and the block size is
8:57
decided by determining a gas limit no every time someone sends a transaction
9:03
to to ethereum Classic they have to put a gas limit
9:08
it's measured by gas and each each transaction can have a different level
9:13
of complexity and and you and more or less each each transaction has a gas
9:19
size and then you pay for that gas and there's a gas price um so when you said now um here
9:29
classic is set to 8 million gas and that determines the block size uh in in bytes
9:37
um it's more or less because um a transaction that is the same amount of gas can have different bites than
9:44
another one because it the transactions are more complex that this is why the
9:49
the gas system was created cre a common uh a common uh quantity variable uh that
9:57
would be e easy to quantify these things so the gas limit at 8 million determines
10:02
a block a block size which is which has an average block size and if the block
10:08
size is increased from 8 million now now it's not said 8 million it's 8 million
10:13
is the default and it's where it's where it's hovering unless the miners decide
10:19
to change uh the miners can decide to change it for example arbitrarily in November of last year there were miners
10:26
that decided to reduce it to 1 million instead of increasing the block size
10:31
they reduced it nobody knows why that happened and some people were having problems sending transactions and smart
10:38
contracts so we did a lot of noise on on social media and they we turn it back to
10:43
8 million which is which is where ethereum and Etc had been floating for a
10:50
long time um and and and it remains now in
10:56
ETC like that as long as Etc doesn't have all the blocks uh filled with
11:02
transactions and new smart contract deployments like that so the problem the
11:08
main problem is bloating uh of that's the way I see it
11:13
um and the second problem is that the miners can can change arbitrarily
11:20
according to their uh business model and their biases the block size and I think
11:26
that this is uh risky because in in etherium they they consistently
11:33
increased the block size um from where it was the the 8 million increased it to
11:39
to 10 million then to 12 million by the time they were migrating to to uh proof
11:46
of stake they changed it to 15 million and the ethereum blockchain is extremely
11:52
bloated so I think that it's it's important for two reasons to fix the gas
11:58
limit and and take away at at a certain level say 8 million I I would I would I would
12:06
consider range between 8 million and 15 million 15 million gas limit per per
12:13
block in order to control the size of the blockchain in the future and to control bloating and also take away from
12:21
miners I think that no one should have uh this this arbitrary decision uh to to
12:29
change the the block size whenever they want the block size is something that is fundamental in a blockchain it
12:35
determines future centralization or decentralization of the system it determines whether people can
12:41
participate in other parts of the world in the blockchain or not and therefore
12:47
it it it uh it um permin permissionless and sensorship
12:54
resistance uh so I think uh the best uh path would be to fix to set the block
13:00
size at a certain gas by protocol nobody can change it except if there's a hard
13:07
Fork uh in the future which is how Bitcoin is configured and I would use Bitcoin as the example blockchain
13:14
because Bitcoin uh I think we can that it's the most successful blockchain and
13:20
and it's the biggest one and it's the original one and it's most secure and the most aligned with um atc's
13:27
philosophy of code is law
13:32
I think there's a lot of Merit in what you're saying and actually agree with basically all of it I think um one
13:40
notable point is that the blocksize debate in Bitcoin world ended up causing
13:45
a chain split and the big blockers went away on bitcoin cash if I remember
13:52
correctly yes the uh the in in the end the the it it was very interesting
13:59
because the great majority of people because the great majority of people in this industry don't understand
14:06
things things they don't areation and permissionless distances are very
14:14
difficult philosophical and principles to understand mentally uh even today I observe that
14:21
more than 90% of these things they only so people focus only on technical things and
14:30
easy to understand commercially and business-wise topics like saying oh Visa
14:38
many transactions coin two little transactions oh we have to Mo be like
14:46
Visa that that kind of thinking exactly opposite of how you should think um and
14:53
um um the so the great majority of people were yeah yeah let's increase coinbase
14:59
zapo at the time all the all the Business Leaders at the time in 2017 of
15:05
bitco yeah yeah let's increase Barry silbert even Barry silbert and and they did a meeting in New York and they got
15:11
80% of the miners and the exchanges all the economic notes and and the block
15:17
explorers and all the leaders and they all signed documents saying we all agreed to increase the block size and
15:22
there were very few core developers of Cipher punks who really understood the
15:28
thing that they they they did the excruciating work of explaining each one
15:33
one by one doing meetings and everything why they were wrong slowly uh they turned the tide and the
15:41
majority in the end said it's a bad idea to increase the block size so a minority
15:47
did split uh that they they were like a hard almost stiff necked uh
15:54
uh stubborn minority who decided to to break off Bitcoin and create the Big
16:00
Blocks and that's Bitcoin cash this is why I say that Bitcoin cash it's flawed doomed by Design
16:07
Bitcoin cash I think they have a block size that is bigger than 32 megabytes per per and and Bitcoin SV as well and
16:15
they're totally bloated and uh they're broken they're broken by Design they cannot scale uh without being
16:22
centralized it's more or less like proof of stake proof of stake it's it's centralized at scale and big block proof
16:29
of work blockchains are also centralized at scale but they did break away and
16:35
they were a minority at the time yeah that's right and I think a a
16:40
point that is not made enough during that debate is that the one of the main
16:47
disadvantages of changing the block size once is that you open the door to doing it again and again in the future which
16:53
is exactly what happened with Bitcoin cash right once you start making changes like this the protocol is no longer aifi
17:00
and it is under the control of some social group that have decided to change
17:07
it and once they've done it once they've kind of captured that chain and can do it again in the future if they want so
17:13
having a commitment to rific on a political level makes it more difficult to change things in the future
17:19
which is really what the goal should be to avoid
17:24
capture um hi guys um I wanted to add something else to this discussion and
17:32
maybe the comparation between uh Bitcoin and etherium in this case is not fair
17:38
enough um and I think that because uh the block size in Bitcoin only
17:44
represents uh like uh size and in in ethereum it also represents
17:52
computation and that's a a main differ because uh in in many cases the the this
17:59
ability uh to reduce the block size through a a mechanism from from the
18:04
miners to to vote to to reduce the size of block has been useful and and a
18:09
protection for the network uh there there were some cases and it could and
18:15
we may have the same situation in the in the future when uh some vulnerability
18:21
has been discovered on the protocol or the or or the implementations of the of
18:27
the op codes or or something that where uh for for like like uh pennies uh
18:34
people could attack the network like creating big uh
18:40
full um blocks which are really really hard to process for the whole network so
18:45
in those cases the protection was to ask the miners to reduce the the block size
18:51
and that was a like like a temporary solution up until the developers were
18:56
able to fix the thing and to release new new versions and and that process is
19:02
way faster than coordinating a new release asking everybody to upgrade and
19:09
make us uh to develop the the solutions and testing and all of that could take
19:14
weeks uh while changing the the gas limit for for miners could take like a
19:20
few hours at tops so I think that's that's one point for me to to keep the
19:26
current um the current mechanism um I think we can increase the the the
19:34
the current default gas limit I don't think that will be a huge problem if we don't go mad with with a number I think
19:41
some number as as Donald said between eight and 15 million may be reasonable
19:47
we should run some testing on how that will affect the network but I think we
19:52
could be okay with that uh but changing the overall mechanism I think it's a
19:57
it's it's not a great idea also there is also some other point that it might be important that I think it's important
20:03
that the the protocol or the network survives the developers so there will be some point where the de I mean we are
20:11
now in like in the developers age but there will be some point where the protocol and the the whole network will
20:17
be aifi and nobody will need us and that will be like the the like like the
20:23
heaven for for the network when there will be no developers involved on this so at that time we cannot ask anybody to
20:30
change these kind of things in in in attack situations or maybe in in a high demand situations or many other
20:37
situations so I think that's also important that which can be managed
20:42
outside the the the protocol itself should be managed outside from the the
20:48
protocol itself um so well that those were my my two points that we're thinking about all
20:54
this yeah these are points I also agree with I generally think the gas voting
20:59
mechanism is a pretty good solution although maybe not perfect because it avoids the hardfork
21:07
problem to change the limit and reduces the chain split potential in future like uh we don't know future Hardware
21:13
advancements or transaction types or potential vulnerabilities that might need the limit to change and having this
21:20
voting mechanism provides this uh in a kind of elegant way
21:25
to to manage that limit um whilst maintaining protocol alific if it needs
21:32
to change in the future given that they could change it anyway at any point by Harding this just means they have a a
21:40
way to mediate that process without causing a chain
21:50
split so I will continue by as ronian is
21:55
not here I will put forward his uh position and just read out what he
22:01
posted on Discord to provide a counter balance to uh the the current debate so
22:09
Ronan observes that the 8 million gas limit is a drastic restriction for the 2024 application development standard
22:16
currently most development teams are operating at around a 30 million gas limit therefore the 8 million gas limit
22:21
is restricting the smart contracts that can be deployed to ethereum Classic leaving it as a disadvantage to other
22:28
evm networks like s Foundation which is the evm ETC aims to maintain protocol parity with to remain state of the art
22:35
protocol par logic states that we are trying to provide a similar development environment with the F foundation for debt development in the application
22:42
environment we have Min minimal differences notable are EIP 15 F9 that
22:48
was excluded due to its impact on the fixed monetary Supply however we have a voluntary difference of 8 million gas
22:54
limit versus a 30 million gas limit on E this restricts the the smart contracts that can be deployed to the network
23:01
current evm application ecosystem is developing around 30 million gas limit if the goal is for applications on E to
23:07
easily migrate to Etc due to protocol parity it's logical for the glass limit to be the
23:13
same different effects contract size reoccurring calls deployment scripts and
23:20
more oh hey Ronin you just appeared as as reading your position I'll finish it
23:26
off and then maybe you can uh add some as I just wrap up here so how to adjust
23:32
current method is social consensus then alerting the mining ecosystem change does not require a hard Fork it's merely
23:38
social likely needs to be documented SL justified in the ecip process once
23:44
changed should take about two days for gas limit to raise from 8 million to 30 million rationale this allows the
23:51
application layer to grow and support more complex contracts like Advanced lending borrowing protocols allows 2024
23:57
state-ofthe-art application to be deployed to Etc this should help produce
24:02
a lucrative free fee market for Miners and earn more than the chain emissions
24:08
also this should allow Etc to gain intellectual human capital in the bare application space enables chain agnostic
24:14
evm development with the largest application layer evm Community a big
24:22
outside hey sorry about that I thought uh I thought this started in 30 minutes so I must have been off have you guys
24:28
been on for since six or for about 20 minutes yeah we started at uh 1200
24:36
UTC oh I see I see sorry uh daylight savings stuff um anyway so so uh so I
24:44
guess uh listen I don't have the solution here I uh my real interest in
24:52
this is that I'm seeing this as an observed um issue when I talk to the
24:59
application layer uh space so dap developers and such and uh and big
25:05
integration Partners uh or like uh infrastructure Partners like um price
25:10
Oracle feeds uh bridging um a lot of this uh stuff when
25:17
you're connecting EVMS and and talking about uh an interoperable evm
25:23
ecosystem um it's it's a pain point because no other network is that low on
25:31
gas um and so that's really the the concern there and so the default that
25:38
most Builders accept uh right now is the 30 million gas limit on eth Main net um
25:45
but other chains have higher gas limits and and all sorts of stuff um but really my interest is more on the friction
25:53
that's created from this um I ALS Al understand uh the concept uh
26:01
that um this could create blockchain blow uh you know are we always going to
26:07
uh follow eth mainnet uh every time they adjust the gas those type of uh questions um my specific uh perspective
26:16
right now is just trying to get uh ethereum classic the evm up to date to
26:25
2024 um so it can capitalize on it's hash rate and Security in the
26:31
application space so um so that's really where I'm coming from outside of um any
26:38
sort of thing of like hey I want to set a a hard rule of that we always do this
26:45
or or um or we need to fix the gas limit or anything like that I think those are
26:51
much more complex uh conversations because I think we would all agree that
26:56
um the current current method of just the miners really decide whatever they
27:01
want uh um is kind of kicking the can of of the gas limit in the long term um but
27:10
just in the short term and specifically uh where ethereum classic is today where
27:15
the DAP ecosystem is today um the 30 million gas limit is the industry norm
27:21
and best practices and not every contract hits that um but what we're
27:27
seeing is that um as you get into more sophisticated or or just more evolved um protocols when
27:36
you move from the V1 protocols into the V3 version protocols the contracts get
27:42
bigger and that's where we run into issues so if we're trying to set up the composable DAP Eco uh uh infrastructure
27:50
for um a robust um uh dap environment to
27:55
thrive on classic uh we need to think about that of okay if we want 2024
28:01
protocols on classic um we likely need to at least consider uh matching the eth
28:09
gas limit because that's what most people are developing to um I don't I I
28:15
just to clarify I'm not saying we should always follow eth it's just specifically because we are trying to catch up to eth
28:22
and trying to gain those uh those dap developers and all of that and um and a
28:28
lot of Protocols are uh set up in a way that they function like it's a three a
28:34
30 million gas limit and that's not just contract deployment it's also reoccurring calls like um for instance a
28:42
multi-chain call right so so you have you can you can adjust uh the size of
28:48
that so that's something that's probably less uh burdensome but also um
28:53
deployment scripts right uh you'd have to rewrite all the deployment scripts and so it's just it's just those type of
29:00
things that I think uh are important to have on the radar um as we have this
29:06
conversation yeah thanks for that and I totally uh appreciate both your and
29:12
Donald's position here I think they have a lot of Merit like obviously previously
29:17
I used to support super low gas limit for the reasons that Donald mentioned before at the same time you are right
29:24
and as a contract developer I definitely see the Y usefulness of being able to
29:29
like migrate code easily and not having to rewrite stuff just to use with Etc
29:35
feel like that would be a massive loss in terms of utility for the network and
29:40
it also May limit future L2 technology if large proofs can't be published to
29:46
Etc my main problem however is that increasing the block gas limit seems
29:52
like a very blunt force means to solve the problem cuz really we just want to be
29:59
able to enable some transactions that are really big to go through without bloating the chain and I think there
30:06
might be a potential for us to come up with a solution that allows us to have big transactions whilst also not
30:12
increasing bloat and that would mean somehow having transactions that go uh
30:19
having some kind of gas credit for example that allow them to either mine some kind of token in the
30:27
future sorry mind like a native gas token for example that can be used in transactions or some kind of dynamic
30:33
mechanism that allows future gas to be used in a current block so that bloke doesn't increase but complex contract
30:41
cont complex transactions and contracts can be used and that is like a big
30:47
complicated change I know but I think it's the only solution that satisfies both um developer adoption concerns and
30:55
the uh loo concerns that over
31:03
raised yeah I think that I think that's a great point of uh you know where we
31:09
don't want the 30 million gas limit for all transactions all the time right it's it's regarding specific type of uh
31:18
contracts that you're trying to put online it's not uh oh every block should be 30 million guests um if that's
31:25
plausible in some sort of way uh that'd be great um even if it was like oh at
31:31
the I mean the way it's adjusted right now is so manual in the sense that miners just s adjust the fee even if it
31:37
was oh at the beginning of the month two days you get uh you get to deploy a 30
31:42
million uh gas limit contract so that anyone that had the big stuff they know every 12 times a year they have an
31:49
opportunity to deploy it to main that um something like that I know that that's
31:54
that's not uh feasible but I'm just trying to hide highlight that uh I do agree with you that um you know for most
32:02
blocks you will not need a 30 million gas limit right it it it's it's
32:07
unnecessary it's really for very specific protocols to get online uh that
32:12
will help improve the fun or increase the functionality and utility of the evm
32:22
so um the need of the 30 million gas is
32:27
for for specific actions that are deployment of certain
32:35
contracts yeah so what what we're seeing is we're seeing uh you know very early
32:41
contracts like a uniswap V2 let's just use that as an example very light
32:46
contract doesn't have complex logic or anything like that so that one uh pretty easy to deploy on this network um we did
32:54
Unis swap V3 um that was gener fine in terms of deployment um in some of the
33:01
operation we had to adjust it because it uh its logic was built around the 30
33:06
million gas limit but at the end of the day that ended up not being too big of a lift or anything uh we had that resolved
33:13
you know you know once we identified it fairly quickly um but as you get into
33:19
some more complex uh lending and borrowing protocols and the evolution in that type of
33:25
space we're starting to see people struggle to get into the 30 million gas
33:31
limit uh because they have complex contracts so um a prime example that I
33:36
identified was while at eth Denver was um uh a company called
33:42
curat they're launching right now and they're struggling to get under the 30
33:47
million so that's just an example of how the application layer is evolving to
33:54
start hitting the limits of a 30 million uh G limit contract and uh anyways it's
34:01
it's just I think the the Highlight the difference here is um are we trying to
34:06
if are we are we trying to have friction where the application layer space
34:11
everyone including if we want to do uh price Oracle integration bridging
34:17
integration every single element um if we want them all to look at Classic and
34:23
go okay we all we have to do custom engineering time to add anything into
34:28
that Network so we're going to put it on the back burner because it's going to cost us way more than any other n evm to
34:35
deploy and then when we get around to it uh we'll add support for ETC um so
34:41
that's kind of the Dilemma that happens when we have this low gas limit um and
34:47
that's the problem that's the friction so do we want the friction there uh or do we want to resolve that and uh if we
34:55
resolve it is it a dynamic way of what a stor is talking about or is it simply um
35:01
asking the miners to raise the limit um is there social consensus for that those
35:06
are those are kind of all the things but right now um in integration talks when I
35:11
mention hey the gas limits only 8 million every single team goes oo is I'm
35:17
gonna now I'm gonna have to adjust our deployment script now I have to look at every single contract and see what is
35:23
hitting over that eight uh eight million limit it's not like it's 20 million right it's 8 million so that's
35:30
substantially lower than 30 million um so so you run into it all over the place
35:35
and then you know you wonder oh why isn't Etc um integrated in all of this
35:41
dap ecosystem and and and that's the friction right there engineering time is expensive so um so that's really the
35:48
case for it of of thinking about the logic of we're maintaining protocol parity with eth main net so that the DAP
35:56
ecosystem can easily Thrive between the two yet we're restricting
36:03
voluntarily deployment and we're making it all custom compared to making it
36:08
similar we we always say oh all the code you don't have to adjust it at all that is 100% not true based on the gas
36:17
limit and I actually see a big opportunity of enabling developers to
36:22
deploy contracts that they can't on ethereum mainnet to ethereum Classic because of this
36:28
potential even though it might be super expensive to call that transaction to
36:33
deploy but if there's no upper or a much higher individual TX limit but uh
36:42
overall no increase in bloat then it seems like it's a
36:50
win-win and you'll have new projects that um are waiting for Earth to increase the gas limit or can't deploy
36:57
and need to optimize deploying to Etc
37:06
instead sorry are you are you speaking in the dynamic sense of of where smart
37:11
contracts have a different a different limit versus transactions I I would say like any any
37:17
transaction if people are willing to pay a massive amount of gas at some uh some
37:24
higher price than they normally would then as long as it's not increasing bloat overall it seems like a win to
37:30
enable that even if it's larger than the block gas
37:39
limit sorry Chris did you want to jump
37:44
in yeah I'm not against uh changing uh the gas limit here but uh for doing that
37:51
I would like to do some research and it seems that uh you might know up front uh
37:58
on my questions like uh Ronin if I'm correct uh you mentioned a contact uh
38:05
that you found at Denver at Denver which was called Curve something I wasn't able
38:10
to hear it correctly so I would like to find out uh actual use cases actual
38:16
contracts that cannot be deployed uh because of uh the requirement of having
38:23
a lot of gas uh the reason for that that is
38:29
that uh I was in belief that uh by changing that limit it had on
38:37
ethereum specifically to 30 million it was for two reasons one for handling
38:42
more transactions and two for handling uh transactions with a bigger
38:49
size with regards layer to transactions and blob transactions and all of
38:54
that uh so not for just an individual deploy
39:00
transaction so I don't think this is a limitation but I would like to to find
39:07
if it is and work on that next to that uh on the having a fixed gas limit on
39:17
the protocol I think I don't like this idea uh one thing that uh could be discussed
39:25
is to have minimum and maximum cap defined uh so as miners cannot go crazy
39:33
and set it 1 million yeah that's that makes sense but make this fixed in the
39:40
protocol uh creates new new new problems uh with regards some things and last of
39:49
it um having 30 million or 20 uh
39:59
uh changes some Dynamics as well like centralization if we have blow of SE
40:07
transactions that come into the network and not as isor mentioned of having u a
40:15
requirement of bigger price to pay bigger price uh for uh huge transactions
40:24
then uh the CH the size will be bloated and this would mean that uh the ciz we
40:31
will have more calization because we will not be able to have a lot of users running full
40:38
nodes so at the end you have less full nodes and you have more
40:44
centralization then uh of course the we we have to manage the the blo in size
40:51
and see what to do with that and uh we are not sure about
40:57
how the gas price will be changed with regard to the markets not that it is an issue right now on ITC but in in general
41:06
idea so first I would like to see uh
41:11
contracts that have the requirement to do that and uh the last thing uh not I
41:20
said that the previous was the last thing but uh I'm not sure if you are able already
41:26
to do a transaction with more gas gas than the
41:32
limit I think you might be able to do that with transaction version two and in
41:39
if this is possible then the miner the miners will be able to see in the their
41:45
transaction pools that okay how someone has this requirement and if I change my
41:52
gas limit a bit up then I will pick up that block and win so at the end it's a
41:58
win-win situation but I have to research that because it has been a long time that I tried to send a bigger
42:04
transaction to the network um there is also another Point
42:11
uh regarding the comparation about the 30 million that ethereum has and the 8 million that we have is that uh ethereum
42:18
has the 1559 enabl so they have an incentive uh on the on the grass price
42:25
to uh to make blocks uh half full so
42:32
when when the block starts like getting really full the gas price the base fee as they call uh starts increasing almost
42:40
exponentially in some some way of exponential growth so that makes that um
42:46
people will try to keep the the prices pretty lower um and trying to reach not
42:54
full logs so that's something that that allows them to play with the 30
43:00
million uh gas limit blocks so that's something that they have we don't uh
43:06
including some sort of 1559 on EDC it's something that uh we were talking about
43:12
we are try we are researching um if that will fit Etc well I mean the idea will
43:19
be to do the same mechanisms without the the burning Fe that the 1559 has in in E
43:26
and ethereum but um that's also something worth to mention I think uh it's it's not as simple as as just
43:33
Rising it to to 30 million without that
43:39
mechanism right was um I did look into 1559 at one point and I believe there
43:46
was something unique to ethereum that made it not really compatible with
43:51
Etc am I remembering that right I think the main difference there
43:58
I mean or the the main problem that we will have for integrated indc is that they will burn the the base fee so as we
44:07
have a fixed monetary policy we can do that but uh for the other feature that's
44:13
see the the other transactions where it's mandated to to pay at least the
44:19
base fee defined by the network I suspect that we can include
44:24
that but it's something that under research
44:30
okay but they would still have Fally you had s sorry there's a bit of lag on this
44:36
one um they they would still fundamentally have the same issues in terms of overall bloat they're just kind
44:43
of incentivizing the averaging out of transaction fees really is that right yes
44:53
M yes but but they have another mechanism that we don't have right now just this Inc incentive to to keep the
45:01
the blocks at the half
45:07
size and then as stora you had mentioned I didn't even think about this but uh in terms of the rollups uh when we start
45:13
getting into a scaling debate of how this gas limit plays into that um I I
45:20
technically don't uh don't know much about um the settlement and how the rollup settles settles down on L1 and uh
45:28
and its size and everything like that I know um in the recent uh update on eth
45:34
Main net um they're putting in scaffold te for Proto dank sharding and things like that and then there was some stuff
45:41
about uh L1 or L L2 settlement on L1 so
45:46
um that's definitely something to add into the mix of this uh and just so just so I'm clear um to you guys I don't have
45:53
the answer for this I'm glad we're talking about the security concerns and everything I think it's really important
45:59
that we have a very detailed conversation about this before any action happens because um as you can see
46:07
there's there's a lot of ramifications when you uh mess around with the
46:13
gas yeah totally I see this as the first explor exploration into the topic and uh
46:20
as it's been brought up on Discord it's just nice to have some uh focused conversation on it and
46:27
there's still lots of ideas of what could be done um looking forward to hear about Cody's Dynamic
46:34
block idea um maybe it's similar to what I've been talking about
46:40
but I think um ideally we can find a solution that
46:45
is finding the best tradeoffs available um um it feels like just a simple
46:53
increase of block size whilst simple isn't really getting to uh a situation
47:00
that satisfies everyone um definitely on Donald's side
47:06
having a having no bloat I think is a really important thing or as minimal as
47:12
possible um but at the same time yeah having having that uh adoption from
47:17
developers is also essential so really trying to find a solution that can solve both of those I think with enough
47:25
thought could be something we can achieve yeah and I'm I'm uh kind of in the same
47:32
uh place as Chris was saying earlier of I'm not really uh into arbitrary limits
47:40
uh just fixing things just because we're gonna we just decide right now um I
47:46
think the concern with that is you don't know what things will look like in the future
47:52
um and having a hard rule like that is only going to to create a contentious
47:58
environment when it becomes uh a problem for the network um you know
48:07
someone will come back and say oh well those people on that call set that random arbitrary number of oh I think 15
48:14
million is the max we should ever do um we have no proof that 15 million is
48:20
great for the life of this network at all so I think I think hard rules like that uh probably aren't great I I think
48:27
an approach uh of a Dynam Dynamic approach where you uh maybe treat smart
48:33
contract deployment that uh a little bit different than just everyday transaction makes a lot of sense um because uh as as
48:42
you were mentioning uh you know that uh that doesn't contribute to blockchain
48:47
bloat um and then and bring in some of uh the concerns with uh uh
48:53
centralization due to such a big blockchain and people can't run uh a full Noe and everything so um so anyways
49:00
I just I don't think that just a hard rule of oh let's just fix it to any arbitrary number makes a lot of sense I
49:07
think with 1 million gas limit which was already attempted to do uh that would
49:12
make no sense today so that's a prime example of how a hard rule today probably won't make sense in five years
49:19
from now um and then and then this network has a long life ahead of it and
49:25
so any of these hard rules uh likely will be obsolete in five years a decade
49:31
from now definitely in 20
49:39
years the the problem is loo one side that's that's the Restriction the
49:45
physical restriction that that um that we are facing no the
49:52
physical restriction of of bloat because it creates
49:57
ation future um yeah the second one the secondary one is whether we have group
50:05
of humans objectively saying okay now block up now block down now block up
50:11
like that I think that's we have to eliminate subjectivity um protocol I understand
50:19
and I agree with everybody sorry can I jump in Donald because I feel like in a way because
50:26
it's minors that are voting with their hash rate it's only as subjective as the
50:32
actual consensus mechanism itself so I don't I don't see where the extra
50:37
subjectivity is coming from it is that there's a group of
50:44
humans deciding the block size um time to time um but yes they
50:51
have to do it within the rules of the protocol and um and they
50:57
the uh I think it's what Diego said that that when whenever there's a problem
51:05
it's useful to be able to manipulate manually the block size solve the
51:11
problem while we go while we solve the the bug or whatever it is to then opgrade in the future it's a good
51:19
shortterm way of um
51:24
solving problem so I I I understand that I also appreciate that Ronin Ronin said
51:31
we don't know what is the perfect block size that that's true like I said before in Bitcoin they don't know what is the
51:37
perfect block size so that that's something that we may never know we don't know what what
51:44
bandwidths and Computing capacity are going to be in different parts of the world and what's what are the
51:50
optimals to make the workor as decentralized as possible so we have
51:56
these uncertainties um and I I also understand that we need need to adapt to the evm
52:05
standard and to normal Market practices because if everybody's
52:11
deploying Mark contracts at demand higher gas
52:16
limit get get left out of the market and that is
52:22
also not a good situation to be in so this is is the this is the general
52:27
problem I I understand that maybe fixing the the gas block to a number like 8
52:33
million or 12 million or 15 million or 20 or 30 um may bring new problems so
52:40
maybe put a I I think somebody mentioned a minimum now the minimum is
52:48
125k a minimum of four maximum of 20 and
52:54
that the miners can uh wiggle within that range I'm open to studying those
52:59
things I don't have a closed opinion or anything like that the situation
53:12
yet yeah I think it I think it's great I think we we're all pretty open-minded here um in in the sense of I think we're
53:19
we're starting to look at all of the issues around this gas uh gas limit and
53:26
um and and I think that's a good point to bring up Donald of in the long run we definitely do not want uh uh humans to
53:34
just be arbitrarily adjusting things for the network um especially with you know
53:40
um a as the network continues to grow um you don't want that centralized body there that's exactly what we're trying
53:46
to get away from it's clear that uh the current um setup with the gas uh is is
53:54
really uh just temporary right um I don't think anyone wants oh the miners
53:59
can just arbitrarily change uh the gas to whatever they want uh I don't think that that's that's a great model for the
54:05
long term but um uh great point on the uh on the social element there of trying
54:11
to remove uh the human the humans uh input in the long
54:20
run I mean whilst I can understand why putting the additional sort of barrier
54:28
to miners of having them need to do a hard Fork to change the gas price sorry
54:35
the g the block gas limit I don't see it as being a fundamental like preventative measure if
54:42
the if the miners wanted to coordinate socially and say hey we're going to
54:47
change the gas limit to this new limit all they have to do is tweak one variable and start mining that chain so
54:55
fundamentally it's still in their control and I see the
55:01
voting mechanism more as a way to allow them to come to an agreement on what the
55:06
gas limit should be without risking a chain split so I I mean I can see the
55:12
point of making it more difficult but I don't really see how it fundamentally changes the situation that currently
55:24
exists well I would say I I don't want I don't want to turn this into a debate
55:31
because again we are in a good point right now studying this I think what
55:37
what Chris said uh that we need to do the research and and be very smart about
55:43
whatever what we decide in the future about the gas the gas limit but U regarding the you just said
55:52
isor there's no equivalence between having a guy like guys changing the gas limit very easily
56:00
like they changed it last November from 8 million to 1 million rest couldn't uh deploy contract they
56:07
were wrting here that's extremely easy to do even by one mining pool that has
56:15
30% of the mining pool share very easy for them
56:21
just to guide the the block size up or down versus doing a hard fork and and
56:28
coordinating is not exactly the this is why proof of work blockchains are so and not only that
56:35
people can split anyway from arrary hard Forks that
56:41
that special interest groups want to say so there there's no equivalence
56:47
uh saying miners have the power anyway so this means that in Bitcoin you
56:54
can you can change the mon AR policy whenever you want that's also true it's extremely
57:00
difficult um there's no equivalence between one or the other
57:08
meth I can see your point sorry go ahead
57:14
Chris yeah I the time that it happened to that
57:20
Miner was able to manipulate the gas limit 1 million he had more than 30% of
57:25
the G rate I think but uh yeah it's true it can happen for this
57:31
reason I think we can set a minimum cap or requirement not in consensus but I
57:39
mean in in the clients so if somebody wants to modify uh that value in the code itself
57:49
and do it then it will work it's not a contentious rule but uh yeah in CL
57:56
we can have some even warnings or not allow having this cap below 4 million 6
58:04
million I don't know but we can set that I mean uh probably the reason that uh they
58:13
have done that was because they didn't knew what will
58:21
come yeah my theory is that there was probably some misconfigured default like
58:27
some tutorial or some software update that was pushed by one of these po softwares that just automatically set 1
58:34
million and no one really thought about it no one intentionally did it they just used the defaults of this update
58:44
indeed uh yeah and to to clarify in in core gu uh the default is 30 million
58:50
correct or or is is the default set to 8 million uh for Etc
58:58
uh on the next release it will be uh 8 million the pl has already merged uh but
59:04
in this m at this moment it's 30 million yes and this came uh during merging the
59:10
Upstream changes while back yeah I also noticed on uh in in can
59:16
you guys do a PR where uh you guys update um the Mordor uh Network so that
59:22
it also matches um main net because the m one is 30 million as well and with
59:28
that one there's such little hash rate that's actually securing Mordor that um you know I if if I turn off my minor for
59:35
instance uh it goes up to 30 million so um so it creates an environment where we
59:40
have a test net that has the eth main net gas limit and then uh we have a main
59:46
net that has our own gas limit so that that'd be good to just have consistency between those two networks and have the
59:52
um the actual limit enforced as the default I will share uh a link in
59:58
community calls right now it's about PR 620 620 and it says 8 million gas for
1:00:08
both classing and M and this has been merged into Master
1:00:13
two weeks ago oh awesome okay thank you so much for doing that uh it's definitely
1:00:19
something I I've noticed over on uh on the Mordor Network while deploying sorry for missing out uh while merging that
1:00:26
this was coming in the 30 million I
1:00:36
mean uh seems like it wasn't an issue as we're at 8 mil and it seems like mostly
1:00:41
it's the mining po config that controls that so I guess it was something on
1:00:46
their end that they just didn't think about so I'm not sure yeah anyway it it's uh a
1:00:56
debate that's kind of tangental towards the main topic about what we can do
1:01:03
um so for the next stages of this uh discussion I guess we can
1:01:09
maybe I can try and put together a list of all the potential outcomes uh all the
1:01:15
suggestions that have been made in this call and try and figure out the uh the
1:01:22
benefits and drawbacks of each one and maybe compile the arguments that have been uh set forth and then we can think
1:01:29
about what makes the most sense going
1:01:34
forward that's great uh please guys if anyone knows a
1:01:39
codra that is needs uh more gas during deployment please let us
1:01:49
know uh Chris I did oh sorry go
1:01:54
ahead clarify regarding that current 8 million limit is is is really it's not
1:02:01
set by us or the protocol or anything like that just just the miners are are following the defaults it could be
1:02:07
increased to 30 million couple of days very easily by them so um that that's a a mar a free
1:02:15
market thing that is happening right now it's not it's not Etc that is
1:02:22
restricted or that the miners that just uh have it there if if if there's
1:02:28
developers wanting to deploy something that they need a 30 million gas limit maybe they could on social media um F2
1:02:37
pool and the other mining pools to increase it right and I should I should clarify
1:02:44
that uh while I have ran into contracts that are hitting that 30 million limit
1:02:50
it's usually stuff that's being developed now you know in 2024 2023 so a
1:02:56
lot of the older contracts uh are not hitting those limits some of their operations need to get adjusted but
1:03:03
that's immaterial stuff uh this conversation was uh really uh formed by
1:03:09
me just thinking about how people developing today and uh and how they're
1:03:15
developing around that 30 million so it's not like it's a complete blocker for us to get some of the infrastructure
1:03:20
online it is a little bit uh more expensive because it's different engineering time for
1:03:26
integration uh last thing go
1:03:32
on no it's another another last topic that I want to say but if you have a comment about this yeah with regards to
1:03:38
this uh I would think that uh for this
1:03:44
new type of contracts that are being worked now we have to do with blob transactions and Layer Two So currently
1:03:52
we don't have uh on our ecosystem don't have a layer
1:03:57
to uh that is that will use such features
1:04:04
so uh at the moment I don't see this as an issue and uh I'm not sure with not
1:04:14
about the the full technology and what we support for this we have to be in parity and then allow the developers to
1:04:21
come in and build on that but about the gas limit I don't think that we have
1:04:29
to to already fulfill uh the 30 million so as they feel that okay yeah Etc is a
1:04:37
good Network to go but first they have to to display that yeah we start
1:04:42
building on it so let's start the discussion on uh increasing that limit
1:04:49
uh because we want to make use of it uh but this is just my two cents and I'm
1:04:55
open to dis some that yeah I just thought of another conversation I'm uh I'm in in works with
1:05:02
layer zero which is a pretty material bridge and uh and the 8 million gas
1:05:07
limit came up there as well um so uh just just another example of of a
1:05:13
contract or a a team that uh has cited issues with the 8 million
1:05:20
MH I was going to say is that if if the 30 million is really needed every now and
1:05:26
then it would be great if we have a small block fa and that's that's the
1:05:33
network usually operates and then someone says okay I need one big block for this they pay an exorbitant fee it
1:05:41
would be great if the protocol could allow that we don't have to exclude these people they have to pay for like
1:05:48
you said this outside the outside of a limit that would be another thing to
1:05:55
study I think isor mentioned that and was one of his
1:06:01
suggestions yeah that would be good I I don't think
1:06:06
it's possible but what I studied about the protocol that you have the gas limit
1:06:12
the next block can be only as big as
1:06:17
1,4 uh of the previous block so you cannot only pay just come and pay a big
1:06:24
fee and you have a 50 megabyte block no I don't think so I don't think that is allowed
1:06:29
yet in thisbe allow the miners have to change their
1:06:36
values it takes one to two days for these two to change on the network and
1:06:41
then they can submit the transaction
1:06:46
yeah I I assume it would require a
1:06:51
hard if you guys want to play around with this uh go into Mordor there's there's it's pretty low hash rate there
1:06:57
so if you turn on some hash rate you'll be able to play with adjusting the gas limit to see kind of how the network
1:07:03
reacts and everything and it's as Donald mentioned of of its a it's a scale and it it would take around two days you
1:07:10
know to climb up because it just keeps building on uh what was the previous gas limit okay we can only raise it a
1:07:16
certain number so if you produce more blocks then you can raise it uh and and
1:07:21
I think that's a stor point of um how hash rate is really determined mining the consensus on
1:07:28
that yeah and the proposal to allow certain either like a oneoff block I
1:07:34
mean the simplest thing would be to have like every 100 blocks you have a huge block um that
1:07:42
would not cause all blocks to be huge um that would be the most simple
1:07:47
implementation but I guess it would be better to have more of a dynamic system where you only get the big block when
1:07:52
it's needed and that would require uh I mean both those things would require a hard fork for sure because it doesn't
1:07:59
adhere to the scaling strategy that's currently in
1:08:07
use excellent thank you st for organizing this it's amazing that we
1:08:12
have this debate yeah thanks for the great combo guys uh it's nice nice to see us start
1:08:19
thinking about uh where we're going with Classic on the protocol level hopefully aifi but there's just minor tweaks that
1:08:26
are still still need to be worked out yep we're getting closer and unless
1:08:32
there's any final comments that one of you made we can wrap this up I'll leave the floor
1:08:39
open yeah thank you guys thank you guys for being here and for starting that
1:08:45
yeah it's a great way forward for the protocol awesome so I hope we can have
1:08:51
another conversation in the not too distant future I'll try and put together some uh notes on this meeting and
1:08:59
condense some potential path forward so I'd like to once again say thank you
1:09:05
everyone for joining and Stay classy see you soon bye-bye see
1:09:11
you soon byebye thank you guys
English (auto-generated)