ECIP-1047: Reduce Gas Limit to 1 Million #6
Conversation
|
Sorry but this is horribly misguided and just plain wrong. Centralization occurs because of economies of scale. You're cutting your miner's reward per block. This will cause miners who cannot mine profitably to drop out, further increasing centralization at a time where prices are already depressed and thus it is most dangerous. But I bet you're thinking... But what you're actually asking here is to lower the utility of ETC for companies that would like to pay for and use that excess capacity for business purposes. In otherwords you're asking to reduce blockchain capacity and this will trigger a cryptokitties style problem at a time that ETC doesn't even have a killer app yet. This means that companies that were considering ETC because it has the ability to scale to meet their demands will now be forced to reconsider their investment simply from the threat that you would reduce the maximum block size to support the right to a timely full blockchain sync for someone in Nigeria with 2 tin cans, some string and a floppy disk. I can't speak for everyone else, but I know this proposal has just caused my company to put a full stop to all consideration of bringing what we had in development to ETC, which is doubly sad because we were looking at ETC precisely because ETH cannot scale to meet our needs due to exactly this. What's your reasoning? |
|
Adding a small subsidy for running a fully verifying node would encourage people to run more fullnodes and completely eliminate all the problems you've mentioned. Can we get an ECIP for that? |
realcodywburns
added
status:1 draft
|
The alternative is that ETC is not independently verifiable by most users after a few years of full usage. This is also entirely reversible by miners if other improvements are made. |
You're going to need to define "most users", to have that argument hold any water all.
Which would do what precisely for the companies and people that were evaluating ETC right now, but had already moved on to something with capacity to scale to meet their needs? Again, why is there not an ECIP offering a system for a small reward for the people who want to run a fully verifying node, hold the whole chain on their disk and serve it up on demand? Miners make money verifying transactions, shouldn't verifiers who are expected to serve the entire blockchain have some incentive for serving it? Wouldn't that make more sense? The problem with syncing is that no one is offering up blocks. Here's my log from trying to sync for the last 3 mins. The solution to this isn't smaller blocks, it's more people serving them up. |
|
you can copy and paste the template to submit your ecip |
|
Thanks, I may actually do that. Do you think it would make sense to add it to the treasury ECIP? |
|
In case this ECIP passes and gets introduced to ETC we might indeed see gas price skyrocket in value. You may want to use this time of big empty blocks to mine some GasTokens. |
|
Again this would be a less than desirable outcome for everyone in the long run. Instability in the price of gas makes the platform far less attractive for anyone interested in deploying serious use cases. It's one thing to mop up supplies and to start driving the ETC price up. All you need are a few good killer dapps. But once you start messing with the per transaction cost in terms of the unit of account (units of ETC required to get the transaction in), then it really loses its luster. |
|
Cross posting my comments from Reddit... Just following up. It's been 21 hours since I last updated. I fell asleep sometime during syncing and woke up to a fully synced node, but it wasn't really syncing well when I went to sleep. So most defiantly less than a day but more than 12 hours to go from 0 to a fully synced and full verification node on modern equipment. I do have a 1 Gb fiber connection on a static IP, and my computer has 8 GB of RAM a Quad Core processor and a 1TB SSD. The internet is nothing special either. Where I live 1Gb fiber is the default and considered mid range, so I pay about $50 per month for internet access, yet already I can go to 10Gb for $200 per month and they are discussing lowering prices already. This is in podunk Utah, https://www.utopiafiber.com/residential-pricing/ I can only imagine more developed areas have better options. I forgot to mention that I'm connected to my router via WiFi so my connection throughput speed is limited to 100MB/s to allow the wife and kids to stream their Netflix and Youtubes and Facebooks comfortably. So I ask you. Is there really a problem you're trying to solve here? People that want to run a fully verifying node are going to either have the resources to do so, or have a business reason to acquire the resources to do it. They can do it now with the larger more spacious blocks having been the default for years and do so on what amounts to mid-range commodity hardware and there is no reason at all to expect that innovation and minimum expectations of service will not continue into the forseeable future. In the meantime, shrinking blocks at this time literally rang the early warning alarm at my work and I now have to explain why moving to ETC may still be a viable idea. Understand, we have a functional product in testing on Rinkeby and will have to put in a lot of upfront effort to port to ETC because the EVM is very stale. The most important thing to remember is that this gas limit per block represents a maximum utility. A blockchain to a business is worth not one dime more than the maximum amount of work they can put it to per unit of time. If you reduce the maximum size, then you reduce the utility value which then makes other chains much more attractive. I'm the one talking because I care. But I can promise you that for every person who vocalizes a concern there are hundreds who will look, go "meh" and move to something else. It mostly depends on how far along they are in the development cycle. A true enterprise app has a lifecycle with a minimum of 2 year and an average of 5 years. These are enterprises who are early in their cycle and will simply overlook ETC if this comes to pass. That means less users in the future and of course that will make it much easier for those users to fully verify. So it's your choice. |
|
Edit: an analogy instead: If blockchains were stuff, let's say building supplies, miners would be the logistics companies. They have the fleets of trucks and warehouses that hold lumber and nails and drywall and garages to park their trucks in. Encouraging miners to target lower gas limits is like encouraging them to use smaller trucks. This way they can pay less rent for their garages, and since they can now fit fewer materials per truck, they can reduce the size of their warehouses too because, well, there will be less stuff. Yea, they'll make less per mile on their routes because they won't carry as much cargo, but now that's not such a big deal because they're used to big per-shipment bonuses (block rewards). But this presents a problem for some supply producers, especially when there are a lot of producers. If a small company produces artisinal nails, it's not a big deal. They still probably won't have any problems getting their cargo on a truck because nails are small and few (and oh so tasteful! ;). The first issue comes for the producers who make (or want to make) big stuff or a lot of stuff. If a company wants to start mass-marketing nails or shipping prefab houses, they're going to have a harder time getting their stuff where it needs to go, and there are other logistics companies who will be more than happy to give them space on their big trucks. The second problem comes later for the logistics companies, when they've turned away large contracts because they wanted small-bed pickups instead of semi-trucks. The per-shipment bonuses are disinflating, and are programatically scheduled to reach almost 0. The primary source of revenue has shifted to per-mile/per-kilogram revenues and producers have already chosen other logistics providers. I'm not sure what the future holds. Maybe it's artisinal nails all the way. Do you know what the gas needs of something like a zksnarks zero-knowledge proof contract would be? |
|
AFAIK miners should be the ones adjusting this based on what will make them most profitable, while users are free to incentivize miners to move up the block gasLimit. This value is really for miners to come up with on their own, and to optimize their mining software such that it meets the current demand of the network. |
|
@whilei I like what you're saying. I agree with what you're saying. But the last 3 paragraphs are a bit inflammatory and run a real risk of derailing this conversation. I realize you're passionate about this as am I. But can you please edit a little bit to be a little more dispassionate. It's enough to attack something like this on it's merits or lack thereof. There's no need for an ad hominem either direct or implied. Thanks for understanding. |
|
Sure, thanks for saying something. Maybe walking a little close to the 🔥 @pyskell I hope this hasn't offended, not meant to. It just seems very bizarre to me. |
|
High gas limit can be perceived as an issue but there's good reasonings for it. Basicly It's up to the mining pool operators (>90% of the miners don't even care). There might be a better chance to lower it by reaching out directly to the operators. But on the topic of chain "bloat"... |
|
disincentivizing empty blocks == incentivizing spam transactions |
|
can you open an issue or thread on the forum for discussion and add a |
| @@ -0,0 +1,39 @@ | |||
| ## Title | |||
|
|
|||
| ECIP: 1047 | |||
There was a problem hiding this comment.
needs a discussions-to: header field
|
@whilei The analogy only covers about 80% of what this is since the shipping company does not actually own the warehouse where they store their trucks. The warehouse is a shared resource and every participant needs to make their own. I suggest avoiding analogies as they likely won't properly encapsulate the nuances of this situation. The suggestion here to reduce the gas limit is because not doing so ultimately leads to centralization and difficulty syncing for participants of the network. 8 million gas in particular is quite substantial and it takes only 1 year of full blocks to create a weeks worth of syncing on typical hardware. We're seeing this on ETH along with storage sizes of ~130GB. The core of my argument here is that blockchains in general socialize the cost of syncing nodes onto future participants and that the current gas limits, as evidenced on ETH, are not scalable long term. P.S. No offense taken, I didn't even read the pre-edit post so I'll stay blissfully unaware of what may have offended me 😄 @realcodywburns Done. Assuming we'll move all further discussion there? |
|
Hi, wanted to voice my support for this ECIP (actually I don't even think it needs to be an ECIP because it's not a software update, just a miner config choice). I've been running Ethereum full nodes since mainnet was launched, and it's definitely out of hand today. I recently paid over $1000 to put a 2TB SSD in my macbook. As I write this (as per usual) my machine is running Bitcoin and Ethereum clients. Here is what it took to make that happen on an i7 with 16GB ram: Bitcoin: ~3 days (on/off usage) It's actually worse than that. I'm only running a "fast sync" on the ETH node (default), and it turns out, that I don't have access to older transactions. They are simply not on my machine. When I query the RPC for them it returns I'm an Ethereum developer, most Ethereum dev teams do not even run full nodes (archive). This is a huge problem, especially for Ethereum Classic whose existence is only possible because of full node security. I say this because, If you run only a fast sync, you are not validating all transactions, and would not catch the invalid DAO refund transaction. Ethereum classic has a huge reason for existing, and that reason must appreciate the importance of full nodes. ETC's main changes so far (beond the DAO debate) have been very attractive to me: (1) capping the supply. (2a)Commiting to PoW, and (2b) removing the difficulty bomb. Having a reasonable sized full node would be yet another huge improvement over (its friend and competitor) Ethereum, and enable more users to develop on it. I hope I've convinced some people, but really we only need to convince miners. Let's talk about the economics. Over the past year and a half, bitcoin proved to us that smaller will blocks result in larger fees for miners (not the other way around as was previously argued) as payments of its kind are very inelastic. In late 2017 Bitcoin hit its ceiling and tx fees skyrocketed to 30$. This "transaction traffic" had exponential properties similar to traffic patterns of cars. As Pierre Rochard had speculated years before, transactions could handle a much higher fee than they were being priced on bitcoin. In this sense the miners can nearly optimize fees by finding the inflection point where substitution starts happening and then raise the blocksize slowly to follow that threshold. (see this discussion) between Gavin and Pierre. Ethereum classic would be the first blockchain to experiment with these economics and could pave way in this regard (because bitcoin has a fixed limit, and Ethereum just follows what the foundation recommends, which is likely much higher than the market would find). There are many more benefits I won't touch on, but the tldr is that the benefits far outweigh the drawbacks. |
|
100% agree with @zmitton, the current high gas limit is unscalable based on hard evidence of it in the wild. Lowering it is the prudent approach to prevent a catastrophic situation where syncing is unfeasible for most or nearly all participants. As efficiency in processing and hardware improves it can then be raised. As mentioned by @zmitton this ECIP represents a recommendation to miners and changes no consensus guarantees about the network (it's a simple client configuration flag). I'd also like to point out that at the time of the hard fork the commonly accepted gas limit was 4.71 million where it stayed until ETH recommended a gas target of 8 million for their network. Then in September 2018 it was made the default in parity for all blockchains (openethereum/parity-ethereum/pull/9564). This change seems to have caused the increase as we were still at ~4.7 in August (http://gastracker.io/block/6426100) and it started rising in September, jumping up 25% already by end of October (http://gastracker.io/block/6726100). |
|
I support this ECIP because we have the advantage of hindsight and blockchains as Ethereum and Bitcoin have huge node churn rates with little new node growth, which has resulted in large node count losses in both networks. Long term bandwidth growth in the US for example is about 17%, but blockchains are growing at a much larger pace which only means that the synch times for regular users (this is the key, that these chains need regular users to easily run nodes as well) is only getting longer which disincentives people of running nodes in regular machines. On the other hand, disk space for regular users is also a constraint. A 2017 Macbook Pro, a very advanced kind of machine on average, for example, has a disk size of 250 GB, but Ethereum archive node is 2.2 TB, and normal node is 180 GB. A bitcoin full node (archival equivalent I think) is 220 GB. It is a fallacy for those who think that "people can just connect a pen-drive and solve the disk size problem" because that kind of action is typical of a more advanced user, not regular users who just want convenience. As a separate issue related to this, UX is terrible in ETH and ETC wallets and node software. It is incredibly easy to download Bitcoin Core and Bitcoin Knots and just synch the chain for a regular user. For me it's nightmare to download Classic Geth or Multi-Geth and try to set them up as a non-technical user. What more steps do we have to do to complete this ECIP and convince all miners and node operators to adopt it? [if this is a done deal and already approved, and no need for more efforts, then pls disregard this comment] |
|
@DonaldMcIntyre seems it's mostly about convincing miners or mining pools to use the geth config flag specified by @pyskell ( |
|
I’m in to help in this campaign contacting miners |
|
continue discussion #14 |
Title
Abstract
All Ethereum-based chains face a major issue where blockchain bloat has the potential to drastically increase sync times and make it difficult to impossible for users to fully validate their copy of the ETC blockchain.
To mitigate this issue, this ECIP is a request that miners target a gas limit of 1 million which is an 8x reduction from the current limit of ~7.95 million; and well above the average gas size of blocks on the ETC blockchain.
Motivation
Over the past year the ETH blockchain has grown substantially in verification time from less than 1 day in June 2017 to 4+ days in October 2018 and growing; even with considerably powered hardware and recent client optimizations. With maximum gas usage it's reasonable to expect that sync times over the next few years will grow to the point where a normal users and even some businesses cannot fully validate the chain, leading to node centralization and the need for trusted intermediaries.
We have the benefit of hindsight and lower utilization but will face exactly the same problems if we do not take steps to address blockchain bloat.
Specification
Miners can start reducing their gas limit to 1,000,000 by adding the below parameters to their clients. This change will happen over time with each block reducing by a maximum of 1/1024th of the gas of the previous block. More details on
gasLimitBoundDivisorare here.Geth
--targetgaslimit 1000000Parity
--gas-floor-target 1000000 --gas-cap 0Mantis
TBDCode Changes
A more robust method to decreasing gas target is to specify a default within each ETC client. Potential changes are detailed below: