ethereum/pm

Ethereum Core Devs Meeting 114 Agenda

timbeiko opened this issue · 12 comments

timbeiko commented

ACD 114

Meeting Info

Agenda

  1. London Updates
    1. Malicious bloated 1559 transactions ethereum/go-ethereum#22963
    2. Baikal status & next steps
    3. Testnet Fork Blocks confirmation #245 (comment)
    4. Ropsten Stress Test
  2. Other Discussion Items
    1. Gas: DoS protection & decoupling worst/average performance
    2. EIP-3584
    3. Gas API Call #328
AlexeyAkhunov commented

I suggest to talk about more general DOS protection and decoupling worst and average performance when it comes to determining safe gas limit, as I described here: https://ethresear.ch/t/a-third-way-coordinating-the-gas-limit/9297/2

  • 👍4
g11tech commented

Hi guys, I would like to table this draft EIP (regarding building a block access_list and including its fingerprint in the block header) for consideration:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3584.md
@pipermerriam

  • 👍1
pipermerriam commented

@timbeiko I've missed the last few calls. Can you give me and @g11in some context on whether this upcoming call is a good time to propose a new EIP or whether it would be better to wait for a subsequent meeting.

  • 👍1
timbeiko commented

@g11in @pipermerriam if you just want to share the EIP with core devs and give a summary, we can definitely do it on this call. It is still very early to talk about inclusion in future upgrades given that London is still being sorted out and we still have not decided/committed to another "feature upgrade" before the merge.

If you want it added to the agenda as a discussion item, just confirm here and I'll put it towards the end 👍

pipermerriam commented

Yes, low priority, but having it at the end of the call just to float the EIP and get preliminary feedback would be nice.

  • 👍1
timbeiko commented

Added, @pipermerriam !

  • 👍1
holiman commented

I think we should discuss ethereum/go-ethereum#22963

TLDR; 1559-transactions can be arbitrarily large, without the large-ness having an effect on the tx cost for the sender, nor the gas used in the block. The only practical limits are on the implementation side: the 10Mb rlp packet size limit, and whatever limits used in various pool implementations. As far as the consensus-engine goes, a 12MGas block can become hundreds of megabytes. Or petabytes, whatever.

I don't think it's very hard to fix, e..g by limiting the fields to 64 or 256 bits, but I do think we need a last-minute change to 1559.

Suggestion:

require(maxFeePerGas < 2^256)   # Prevent impossibly large numbers
require(maxPriorityFeePerGas < 2^256) # Prevent impossibly large numbers
require(maxFeePerGas >= maxPriorityFeePerGas) # Makes sense that the total is larger than a part thereof
require(sender.balance >= gasLimit * maxFeePerGas) # The sender needs to be able to cover the full max resources he's claiming

Where the fourth rule is the most "controversial". I'm ambivalent myself.

holgerd77 commented

@holiman Does this only affect these two new fields and are there checks already in place for existing fields like gasLimit e.g.?

holiman commented

Does this only affect these two new fields and are there checks already in place for existing fields like gasLimit e.g.?

The important aspect are the new fields. The other fields are already capped in practive, e.g. gasLimit is bound by block gas limit, and gasPrice is bound since gasPrice * gas needs correspond to an actual balance.

It's only with these new fields that we have the possibility of a not-used arbitrary large integer hanging around.

  • 👍2
timbeiko commented

@holiman added to the agenda 👍

tvanepps commented

Can we mention the 1559 Gas API Breakout call?

Date/Time: Friday, June 4 at 14:00 UTC (10:00 ET)
Duration: 60 mins

  • 👍1
timbeiko commented

Closed in favor of #330