Execution Layer Meeting 188 #1043
Comments
|
i'd like to get some feedback on ethereum/execution-apis#542 |
|
I'd like to bring up a topic for ACD that's not necessarily consensus related, but perhaps a nice-to-see-eye-to-eye one across different execution clients. Currently Geth by default has a minimum miner tip requirement of 1 gwei by default. This was the case ever since Ethereum launched (starting at 50 gwei, and going down to 1 a year-ish later); apart of an interim period when some PR broke passing this value to the miner and for a - long - while accepting all transactions, even those paying 1 wei tips. Whilst I have no particular issue with the current status quo, certain people are running around the ecosystem throwing around charts to demonstrate that Geth is mining "bad (i.e. not full enough)" blocks. Point in case (ethereum/go-ethereum#29771, prysmaticlabs/prysm#13998) + a number of private messages where they didn't like my responses so they just keep pushing publicly that Geth is "bad". A little background: when the London hard fork shipped, and we introduced 1559, the most of the miner fees were essentially insta-burned though the base-fee, only the "priority fee / tip" remaining. There was a rough ACD consensus that 1 gwei tip "should be enough" of a tip for miners to keep including transactions, and AFAIK all EL clients when with that. After some time, though whatever reasoning, clients started to pack anything valid into the blocks, figuring that "hey, 1 more wei is still better than no more wei", so might as well push everything they can into a block. This was obviously noticed by the ecosystem, and people started submitting transactions with close to no tip (many currently going at 0.01 gwei and below). So the effect is that unless the network is very congested, people will stop paying any miner tips at all. MEV block builders I think also bundle to the last drop, so they also gravitate towards nuking the miner tips to 0. [Just a random side note, blob fees already pay 0 tips to miners to include, they are only charged the blob base fee; on top of which a relatively minimal execution tip is added - if any, unsure how those commitments work]. The current effect of the ecosystem accepting 0 tip transactions and Geth not, is that blocks produced purely by Geth are more empty, since it refuses to add txs below 1 gwei tip. Interestingly, the value of those blocks is pretty much the same as other clients adding everything, highlighting that there's no economic hit on filtering out the leecher txs. That said, this is an interesting predicament, because we have two conflicting points of view of what the priority fee / tip is (or should be):
Now, I can accept that defaults are powerful, and Geth sticking with the 1 gwei may or may not have been appropriate in the past and may or may not be appropriate in the present. I'd like to bring it up at ACD to hear how other client devs relate to this (both EL and MEV side). Ideally would be nice for ELs to behave similarly - even if they can obviously be changed by the operator. My primary concern is that with the blob fees not paying tips at all; and @vbuterin attempting to spec out multi-dimentional gas pricings that might also not pay tips on all-but-the-legacy dimension; we're giving the MEV builders everything on a silver platter, because apart of MEV, there soon will not be execution rewards at all. EDIT: A followup question is whether the blob fee should also have a miner tip component added or not. |
From ethereum/go-ethereum#29771 (comment)
1.13.12 was in 9 Feb 2024? So if any other client forced a price before the last 4 months, they would have been penalized the other way vs Geth before that time (exactly as Geth is currently?)
Tip is a terrible name unless it can be zero. Saying all that; 1 gwei seems a reasonable lower bound.
Looks like nethermind does force a 1 Gwei min for blobs in tx pool https://github.com/NethermindEth/nethermind/blob/efbe1351e37333a9c2f9cca2f6c9b7be433205ca/src/Nethermind/Nethermind.TxPool/Filters/PriorityFeeTooLowFilter.cs#L15-L24 However currently you are referring to a change in tx pool acceptance by clients; which would make all clients worse vs bulders
Which will cause more concentration in centralized mev building. So is your proposal an eip change to eip-1559 which does not currently specifiy a minimum to make such transactions invalid in blocks? |
|
@karalabe is not suggesting to change EIP-1559. AFAIK he just wants to have a discussion about the purpose of priority fees. |
No. The chart not attached to the comments is the one which states that the block rewards of Geth vs. other clients are the same, because the low paying transactions pay so little that they are a rounding error. So Geth forcing anything does not stand imo.
Priority fee is also terrible, because it's supposed to capture the opportunity cost of miners + their service fees. Open to a better name.
Depends on the threshold. It doesn't make sense to accept 1 wei txs, the quesition I'd like answered is what's reasonable.
No, not at all. I'm not looking for a consensus change. I'm just trying to find a good number for client defaults so that people stop calling us out for being "unhealthy" for the network. |
|
Longer comment here, but what geth is currently doing is "unhealthy" for the network. The median block following geth blocks now hits the gas limit resulting in multi block inclusion delays for valid transactions. The only reason the network isn't severely affected right now is because geth's block share is so small and other builders haven't yet followed suit.
|
|
There was never in the history of Ethereum a promise to include transactions at close-to-zero prices. Miners always set their minimum required prices to cover for opportunity costs. |
If isn't a consensus change won't builders keep doing what they are doing and will just make actual client building worse? i.e. all perform like current Geth Client building is a minority; people will still do 0 since the builders accept, the blocks will pass, less validators will client build because is much worse than builder blocks; cycle. |
@dataalways 's own chart proves that that is not the case and the fees are actually the same on any relevant order of magnitude. For whatever reason, he removed my read rights for those charts so I can't share them, go figure. |
|
|
I also wrote like 6 times already that this should be discussed at ACD if the defaults are not appropriate and what the effects are. But yeah, let's make a 7th public shitpost about how Geth is unhealthy. |
Peter is referring to what was always clearly labelled as a non-public document that existed only to confirm that there wasn't a critical bug in geth that required responsible disclosure. I have made available my full suite of data on the topic at the link below. |
|
I refuse to be dragged through the dirt: 
The miner minimum gas price requirement was always part of Ethereum and Geth. It was added to Geth on May 9th, 2015 (9 years ago). Somebody broke passing the value to the miner during a merge refactor / transition so we fixed it, announced it in our release notes and not only announced in on Twitter but also added that miners should check their ideal values since this might interfere with what transactions they include or reject:
@dataalways seemingly long stopped caring for an intellectual discussion about this topic and has entered into a destruction mode, dragging me and Geth through the dirt for something he doesn't seem to understand. Opening a PR against Prysm with the sole purpose to lower the rate of selecting Geth as a builder vs MEV when he didn't like my responses is beyond petty. He doesn't seem to care for reason at all, he doesn't want to consider opportunity costs to miners, miner fees, etc. He wants his 0 prices tx back and is burning everything in his path to get it. I acknowledged at least 7 times already that this default value should be discussed at ACD if it's having a surprising effect somewhere, but @dataalways still keeps posting everywhere that Geth "unilaterally" "under the radar" "made an opinionated decision to, by default, enforce a 1 gwei minimum tip and intentionally exclude over half of valid transactions in their locally built blocks". He's not arguing here, he is plowing through anyone trying to go against his personal view of how things should behave. I'm sorry, but this is not an acceptable behavior and I will not continue entertaining such people. |
EIP-7706 as written includes miner tips for all three types of gas. I have heard discussions that blobs not paying tips is currently causing some problems in the network, so it feels like adding tips for blobs is good. I would be in favor of geth applying a minimum tip across all three gas dimensions. |
|
I would like a few minutes (<5) to show the relevant portal network specifications for our history network in the context of the recent 4444s breakout session. A few extra minutes to answer any questions EL teams have about our protocol and integration might be useful as well.
Based on the conversations I've had thus far, I believe that our history network is the appropriate and minimal solution that EL clients need. I'd like to engage with EL client devs on this topic to help educate them on what our protocol does and understand what their needs are so that we can find a common interoperable solution to this. |
|
@charles-cooper @karalabe @pipermerriam added each of your items to the agenda! |
|
EOF update by the Solidity team on the R&D discord: |
|
Reth side would love to have a conversation about Pectra in Q1 2025 including PeerDAS + EOF! Here's a longer doc which explains how we think about it. Have already polled some teams but keen to hear how the broader group reacts to it! https://docs.google.com/document/d/1IfOnozIhp93qkqZ7Jt-jVUvcdRDAv7HOdP4lnsOpu74/edit |
|
By ship in Q1 do you mean we start to flip testnets in Q4 2024 or Q1 2025? |
|
EIP-7702. Hopefully we can confirm that it will be included in Pectra in this call. |
We've also listed some options for the fork and added some thoughts around them: https://notes.ethereum.org/@ethpandaops/pectra-fork-thoughts |
|
Thanks @parithosh! I've added it to the agenda. I've also moved @karalabe and @charles-cooper agenda items to the start of the call as I imagine once we get into the Pectra discussion, it will eat up as much time as possible. @pipermerriam I'll make sure to block out the last ~5m for you! |
|
EIP-7623 is currently CFI'd. Talking with people, I got the strong feeling that there is demand for shipping it in Pectra. The latest change involved reducing the floor gas cost from 12/48 to 10/40 in order to make sure that even less users will be affected (especially thinking of Merkle Proofs, Starks, and similar). If there is time, we could take the decission to include it in Pectra. If not, I'm happy to put it on the agenda for ACD in two weeks. |
|
I can't join today's call, but I'd like to bring up There's been significant progress with EIP-7495: SSZ StableContainer.
SSZ enables several improvements:
|
|
We prepared some stats regarding EOF and legacy EVM comparison. It's good to make people read it. |
|
Hi, I would love to make a quick -1 minute- update about the current status of EIP/RIP-7212 (recently added to the CFI list) in terms of rollup and client implementations, then answer any question if there are. |
|
Closed in favor of #1052 |
Meeting Info
#allcoredevsDiscord channel shortly before the callAgenda
The text was updated successfully, but these errors were encountered: