Ethereum Core Devs Meeting 114 Agenda

[timbeiko]

ACD 114

Meeting Info

• May 28, 2021, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/7MSYLbn-Xro
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

1. London Updates
   1. Malicious bloated 1559 transactions [PoC] cmd/evm: malicious bloated 1559 transactions poc go-ethereum#22963
   2. Baikal status & next steps
   3. Testnet Fork Blocks confirmation London Timing #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 EIP-1559 Gas API Call (Breakout #10) #328

[AlexeyAkhunov]

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

[g11tech]

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

[pipermerriam]

@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.

[timbeiko]

@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]

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

[timbeiko]

Added, @pipermerriam !

[holiman]

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]

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

[holiman]

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.

[timbeiko]

@holiman added to the agenda 👍

[tvanepps]

Can we mention the 1559 Gas API Breakout call?

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

[timbeiko]

Closed in favor of #330