I still think a once-per-day change in BASEFEE would be optimal for the user experience. Today, say it’s 10 Gwei. Let the MAX gas float up to 4x the target of 8 million for the entire day. If we use 175 Billion gas instead of the daily 50 Billion target, AND that raises the 30-day moving average above 50 Billion, then the BASEFEE inches up to 12 Gwei tomorrow, and 20% more the day after that, etc…until the average gas usage returns to target. Sure, the state size can grow at 4x for very a few days, but it really doesn’t matter as long as the gas slowly reprices to limit state growth to something sustainable.
Tips would only really be needed (1) to incentivize miners to take the transaction and (2) if the network is under a severe load (whether the surge due to an ICO or Cryptokitties or DOS), in which case it can revert to more of a competitive auction. But set the default tip at 25% of BASEFEE. Everyone knows the gas price, and that it might go up (or down) 20% tomorrow. If a client pays yesterday’s basefee by accident (e.g. they submit the tx a few seconds before the BASEFEE changes, then their 25% tip will be reduced to 5% and probably still be accepted by a miner.
Clients can still opt to pay double the BASEFEE (or more) as a tip for high priority transactions during congestion.
I fail to see why the gas price needs to change so rapidly as every few blocks. It makes for a frustrating user experience. We have the luxury of a low uncle rate now, so there is no barrier to allowing high capacity days to occur.
I am working with Rick on coordinating the EIP-1559 Working Group.
Currently, we are looking for a:
Senior Geth Dev
Wallet Dev.
PM me if you are interested, or know where we can find some. As, @tvanepps told me recently Senior Geth Devs are " elusive, like leprechauns" So, we appreciate any help.
So, let’s talk about DoS. The block gas limit currently acts as a protective measure for short term attacks (mispriced opcodes taking too much CPU resources, ala Shanghai), and long term attacks (state bloat).
The proposed EIP insta-bumps the gas limit to 24M, which would lead to block times of 200-1000ms (just pulled some random numbers from a Geth full node). By removing miners’ capabilities to influence the block gas limit, we also remove the possibility to adjust in case of a future DoS attack. Is this good? Bad? Would be nice to discuss.
Wrt long term state bloat, the bumped gas limit will also permit a 3x rate of growth compared to current limits. The EIP assumes that people won’t be willing to pay for that, but until now we’ve seen that Ethereum blocks are always full. I guess the design is that eventually the basefee grows so large that “nobody” will want to play, so it will fall back down. I can imagine this working out, but would be interested in some discussion around it.
One interesting phenomenon that I see is that users would sign a transaction that actually permits an interval for the fees, but you’ve no idea how much that will end up being. This will make sweeping an account impossible. Good? Bad? Dunno, just stating the facts.
A complication might arise around transaction propagation. Currently transactions have a total order, so full nodes can pick the best N transactions to keep and discard anything afterwards as SPAM). The base fee model could make things messy here, because the total order can change across blocks. We need to ensure that it’s not possible to create transaction propagation scenarios where data rotates in the network indefinitely.
I like these comments a lot. I’m still preparing my comments on the EIP and Vitalik’s paper. I’m less in favor of discussion and more in favor of modeling, I respect that the major stake holders already understand the problems well enough and need firmer numbers and/or code to agree with a proposal. This change is too fundamental to do otherwise. Once I have more details ready, I’ll provide those for feedback, thanks again.
I strongly agree with that. The BASEFEE is equivalent to taxation that people cannot escape from. The problem remains the same: There is limited gas avaible and people will compete with their respective tip that is equivalent to the current fee.
Furthermore (because the BASEFEE is equivalent to taxation) there will be lower welfare. A BASEFEE is also highly unfair since rich and poor individual pay the same fee. Imagine a scenario where there is a period of high network usage and therefore a high BASEFEE and tip. People with high willigness to pay will get their transactions included( probably rich people). Now imagine a period of low network usage where there would be low tips and a person with low willigness to pay could get his transcation included. Problem is that he inherits a high BASEFEE from the previous period. It`s like you’re driving at night to avoid traffic and then the police stops by to say: “Sorry there have been a lot of traffic today please drive slowly” and you think ** because the street is fully empty.
The goal there was to shoehorn the two into one variable as a hack to avoid having to change transaction formats. My understanding is that @AFDudley’s work is NOT going in that direction, and instead it’s biting the bullet on complexity-of-change to “do it right”.
Wrt long term state bloat, the bumped gas limit will also permit a 3x rate of growth compared to current limits
Not in the long term. The reason is that if average gas usage is above 8M/block, then fees will keep going up until average gas usage is at 8M/block.
The base fee model could make things messy here, because the total order can change across blocks.
Hi, I am very interested in this EIP but I have a question about the miner incentives. To be honest I didn’t read through the whole thread here so I hope it wasn’t answered before. What is the incentive of miners to increase the BASEFEE? As the proposal states:
A valid BASEFEE is one such that abs(BASEFEE - PARENT_BASEFEE) <= max(1, PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR)
So as I understand that the miners can decide what the next BASEFEE will be. Reducing the BASEFEE would result in more people sending transactions leading to bigger blocks (up to SLACK_COEFFICIENT * TARGET_GASUSED) and potentially more tips => more profit for miners. What incentives do they have to increase the BASEFEE?
When I first read the proposal I thought there is a deterministic consensus rule which determines the next BASEFEE based on the gas used in the previous block (or maybe better in the previous N blocks?) and the miner has to follow this rule (basically what is now described as “default strategy” but is not enforced in the current proposal). Why not use such an approach?
Hey all
We would like to bring this topic of discussion up during Magicians Council in Berlin. Is anyone interested in to talk about it @econoar@AlexeyAkhunov or anybody else
Indeed, my extremely strong inclination is to figure out the right way to do it and then figure out when it fits in the release schedule.
The current plan is to add a new transaction type and fields to the block. This will allow us to have both transaction types functional at the same time, which is a hard requirement for tooling compatibility.
The current plan is to add a new transaction type and fields to the block. This will allow us to have both transaction types functional at the same time, which is a hard requirement for tooling compatibility.
I support this.
Sorry for the confusion, my proposal will have the increase under consenus.
For those who don’t understand what this means, basically the idea is that in Rick’s version of the EIP, the exact formula for changing the MINFEE will be a consensus rule that miners have to follow exactly, rather than merely a suggestion for miners (as the gas limit is today). I support this too
We commissioned a study from Matt Slipper on Implementation of 1559, including the specific changes required within Geth and a more complete fork strategy. All changes included are additive. Here are a few main points.
Fork 1:
Add new transaction type
Both run in parallel
A transition function that overtime reduces gas available on the the old type and increases gas available for the 1559 transaction type
Fork 2:
Clean up
Unlock any remaining of the total 16 million gas for the new type.
Incentives to adopt the 1559 transaction type
We already have a “stick” in the form of reducing the gas available to the original transaction type. To introduce a “carrot” to encourage adoption by users and wallets we suggest that any gas cost reductions, or gas price updates only be available for the new 1559 transaction type. The implementation study includes how this is possible from a code perspective, and this approach simplifies a lot of the game theory around the transition to the new type.
Starkware recently championed an EIP for reducing gas costs for Istanbul. I have worked closely with them, and there is plenty of room for additional decreases in gas cost in subsequent forks for incentives. Also, any gas updates to individual op_codes are available to us as well.
Looking forward to your comments, questions, and feedback.
James
We’ve put together a brief that outlines the status of the EIP-1559 working group.
Please feel free to circulate with whomever you deem relevant.
Right now, we’re still in the process of soliciting bids. In particular, we want to make sure we get the simulation and modeling pieces right per @AFDudley 's comments earlier, so that analysis can provide guidance on parameters for the community to discuss.
In particular, we are looking for
economists to help with a formal assessment of the fee market proposal
simulation experts that will be able to work with us to derive agent profiles
software development firms which have extensive experience working on geth and Ethereum code bases.
Any leads would be appreciated, and this document may be a good starting point to share.
In addition, we now have an email address!
Feel free to publicly post or DM us here on the forum, but we can also be reached for inquiries at 1559@vulcanize.io
What could ETH user with some basic python / data analysis skills could do to push it further?
Is it possible to donate money for people working on this?
What is the time frame for this?
My main problem for this EIP is that there is no clear champion taking leadership around this change.
The only one to be hurt by the current situation are end users.
Further preliminary data: minimum gas fee “safe low” is gravitating towards multiplies of 5:
The histogram looks gaussian around 10 gwei but also like exponential decay at around 1+
It suggest that there is very large demand for getting sub 1 gwei transactions cleared - but question is what’s the limit of ETH network in this regard?
What’s the optimal gas fee that’s a compromise between UX and maximising the security of the network and network value?
@guthlStarkware we’re targeting Berlin currently. @kwikiel thanks for these analyses. I’ve seen this graph which may be relevant https://gitcoin.co/gas/history
how are you defining safe low/standard/fast here?
with regards to donating money, we are coordinating partners and budgets at the moment.
we should have updates shortly.
