“I’d recommend starting a Reddit/Twitter campaign to promote the cause of pushing the gas limits up. Historically the large mining pools have listened to community pressure.”
The ethereum network is running at full capacity with gas usage at the limit of 8 million per block, translating to 50 billion a day.
That’s while ethereum’s version of orphaned blocks, uncles, have fallen considerably to 25% of the peak in January 2018 when the gas limit was not raised by miners.
About 40% of miners are currently voting to raise the gas limit. That’s F2Pool and Sparkpool. Just Ethermine or Nanopool would be necessary to raise the gas limit, but Buterin says it might be better to wait a bit. He says:
“It’s not clear that exactly now is the best time; it could be better to do a bigger gas limit jump at the same time as the Istanbul fork when the opcodes that present the greatest risks will see their gas costs bumped up so higher gas limits become safer.”
Istanbul has a number of gas related improvements that by themselves may allow for more transactions to be fitted within the current gas limit.
This upgrade was meant to go through within weeks just before Devcon, but some delays due to Parity hardly implementing anything has now pushed it back to maybe November.
As it stands, the ethereum network doesn’t feel congested, with fees at a penny or so, but now and then some dapp floods it with many transactions, so creating traffic for a bit.
Simply increasing the gas limit could be one can kicking solution, but a more effective one might be the utilization of hybrid second layers (L2).
Snarks or starks could increase scalability by doing a lot more with a lot less storage or data requirements through utilizing snarky starks for verification.
This gets rid of a lot of problems that things like the Lightning Network or Plasma have, with Buterin so wondering why not combine snarky starks with Plasma and the like.
How exactly isn’t too clear, but Buterin says a Plasma chain can “periodically publish some per-user data on-chain,” lowering local storage and/or verification requirements with Buterin concluding:
“The hybrid route opens the door to a relatively fast deployment of fully generalized Ethereum-style smart contracts inside a quasi-layer-2 architecture.”
All this presumably would have to be at the backend of some wallet or Metamask plugin to onboard users as you need to first deposit into a smart contract or lock the eth, with you then able to interact only with those users in that smart contract system.
That can have a chicken and egg problem in regards to adoption as all these second layers are useful – or even work – only if people “join.” For people to join, however, it has to be useful and it is not useful if people don’t join, so bootstrapping might not be easy.
To incentivize it, in bitcoin they’re just making on-chain transactions expensive. In eth, they’re leaving second layers as optional, with something like starks based Plasma potentially useful especially for dapps as you have to deposit eth in it anyway.
The incentive there would be making it more convenient for users as with such second layers you would need far less on-chain transactions, and thus less waiting around for confirmations or calculating fees.