To handle peak congestion we will need to be able to sustain >1x throughput for much longer than allowed by 1559, while still amortizing the long-term costs, which are not limited to state growth. There is no reason that bandwidth costs should surge 50x when usage increases 3x for a few hours. Grocers don’t raise their prices in the afternoon; they hire part-time workers.
The elasticity of 1559 is unproven on a congested blockchain, and may not come until PoS due to increased uncle risk under PoW. Consider deferring your judgment about the elasticity provided by 1559 when it wasn’t designed to provide it, but instead to pump the ETH price.
the current plans to mitigate state growth are fully independent from the refund mechanism
If you prefer state rent, I encourage you to live with it for 10 years before forcing it on everyone else. You may find it annoying that the ENS handle you had reserved for 100 years is gone now, the few who have the info you need to prove it back into existence are charging you a fortune for the privilege, and the state size has not actually shrunk because of the stubs. It’s unreasonable to plan around a system that nobody has a good design for, never mind an implementation. State rent is a pie-in-the-sky solution to numb you until we realize state growth is not that bad when we let the miners-soon-stakers who pay for it set hard limits on its growth.
These lead me to my opinion that this introduces significant complexity with minimal benefit.
The complexity is 32 bytes per contract account that stores gas. I don’t recommend storing this attribute on every account by default. The benefit is that this uses significantly less storage for more elasticity than provided in the status quo. If you don’t care about storage you must not run a node.
This refutation isn’t compelling for me. I don’t believe that users would actually do the balance(..) - 1 approach broadly, and beyond this, refunds have not proven to be adequate to provide any meaningful mitigation to state growth. They may slow it down some, and removing refunds might make the problem a little worse… but ultimately, to really provide a meaningful solution for state growth, a more significant change is needed, hence: Resurrection-conflict-minimized state bounding, take 2 - #17 by vbuterin - Execution Layer Research - Ethereum Research
I agree on this. I now understand that 1559 doesn’t provide the type of “supply elasticity” that 3322 proposes. I still don’t see this argument as compelling enough to justify the complexity.
This is the leading model for how we intend to deal with state growth at the protocol level.
The complexity is that it introduces more nuance to how gas is used and accounted for. This will inherently effect many different parts of how the EVM operates. I’m not suggesting that there is anything insurmountable. Just that this isn’t a “small” change, and that I don’t see it being prioritized over the other significant protocol changes that are being worked on.
If you prefer state rent, I encourage you to live with it for 10 years before forcing it on everyone else. You may find it annoying that the ENS handle you had reserved for 100 years is gone now, the few who have the info you need to prove it back into existence are charging you a fortune for the privilege
Hi. Could you help me understand why the “few who have info” will necessarily behave as a monopoly (and charge a fortune)? Why won’t one of them undercut the others? Disclosure: I am researching state rent! Thanks
It would be very costly to maintain a redundant system over time, and few customers willing to pay much of anything, especially at first. Costs are not restricted to hardware; the system must also be maintained by engineers. Due to the cost of maintenance I would rule out altruism after the first several years. The number of providers would be perpetually diminishing; nobody would allow anyone else to copy it cheaply lest they invite competition and ruin the very reason to have preserved the data in the first place. The resulting barrier to entry would result in collusion and monopolistic pricing. Failures to collude would harm all participants, reducing the count until equilibrium allows collusion or an outright monopoly. Mergers are likely collusion strategies in this scenario.
It’s not so much about the users as it is about the protocols. Most end-users do what the UX tells them to, and the protocols with the most users will have earned them at least in part by minimizing their gas costs.
On the contrary, it uses an existing mechanism, the refund counter.
Thanks