Why to derive tx.fee_premium and tx.fee_cap from tx.gasprice uses 2**128? Does not that large number produce some issues in other languages?
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.
Interesting! What do you mean by this?
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
BASEFEEis one such thatabs(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?
1 Like
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 
Would you like me to discuss it?
Sorry for the confusion, my proposal will have the increase under consenus.
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.
3 Likes
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
1 Like
Update:
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
1 Like
Hello Magicians,
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
Thank you.
1 Like
I would really like this EIP to be implemented.
I’ve started gathering data on gas fees - I don’t know if somebody has similar charts already
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?
3 Likes
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.
1 Like
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?
1 Like
@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.
1 Like
Why would the miners ever raise baseFee?
Great! One solid way to do this would be to set TARGET_GASUSED as a hardcoded value, especially for Ethereum Classic.
Incentives
The full-nodes are the ones that have no input, output, or incentive no matter what you do to this market (it is between miners and users alone). Full-nodes are essentially volunteers so hard coding the TARGET_GASUSED low enough, such that anyone interested in running a full-node can do so without significant cost. Of course “significant” is a matter of debate but having users or miners affect this value is worse than developers, as their incentives are known to be different than full-nodes, however there is no way to get a sybil-proof opinion from them so as a consolation the devs (having less of a conflict-of-interest) decide. Ethereum of course has different security tradeoffs so I would love to know if you have a different variation. link?
Making things better for full nodes should be addressed other ways. the purpose of the gas price is not to make things easier on full node operators, a different mechanism should be used.
look for champions soon (hopefully)
For the existing proof-of-work system it may actually make more sense, instead of just burning everything collected in BASEFEE, to put some or all of it in a fee pool to be distributed equally among the miners of the following x blocks. That way you preserve the current incentive structure for miners as a collective where they want total fees collected to be high, and you should be able to also keep the current system where miner voting controls the network’s capacity.
If you burn all the base fees, the next step seems to be to say, “OK, we can’t trust miners to control this so we need to replace the miner voting mechanism”, and you end up potentially shaving a lot of yaks unrelated to the original fee market improvements.
1 Like