Ethereum Core Devs Meeting 95 Agenda

[Souptacular]

Ethereum Core Devs Meeting 95 Agenda

• Meeting Date/Time: Friday 4 September 2020, 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream

Agenda

1. EIP Discussion
   a. Potentially removing gas refund (see comment).
   b. EIP 2718: Typed Transaction Envelope (general-purpose standard for adding new transaction types).
   c. EIP-2929: Gas cost increases for state access opcodes.
   d. EIP-2930: Optional access lists.
   e. EIP-2315: Simple Subroutines for the EVM.
   f. General discussion on the idea of combining some of the above EIPs that create a new transaction type, so we just create a single new transaction type that has a whole bunch of the features together.
   g. EIP-2935: Save historical block hashes in state.
   h. EIP-2711: Sponsored, expiring and batch transactions.
   i. EIP-1057 Next Steps.
2. EIP & Upgrades Updates
   a. YOLO / YOLOv2 & Berlin state tests update
   b. EIP-1559 Update
   c. Account abstraction: AA EIP and AA DoS study (cllick here for comment with links)

ACD Note for YOLOv2 (From: Hudson and James):

We want to focus on what should be included in YOLOv2 rather than what is officially going into Berlin because there are things like benchmarking and further evaluation of CFI (considered for inclusion) EIPs that usually advance an EIP from CFI to Accepted.

We recommend considering the following EIPs for YOLOv2. Note that not all of these EIPs are in CFI, but are to be discussed in ACD Meeting #95.

• EIP-2046: Reduced gas cost for static calls made to precompiles.
• EIP-2315: Simple Subroutines for the EVM.
• EIP-2537: Precompile for BLS12-381 curve operations (already in YOLOv1).
• EIP-2711: Sponsored, expiring and batch transactions.
• EIP 2718: Typed Transaction Envelope (general-purpose standard for adding new transaction types).
• EIP-2565: Repricing of the EIP-198 ModExp precompile.
• EIP-2929: Gas cost increases for state access opcodes.
• EIP-2930: Optional access lists.
• EIP-2935: Save historical block hashes in state.

Next call: September 17th, 2020 14:00 UTC

[vbuterin]

• EIP 2718 (general-purpose standard for adding new transaction types)
• EIP 2929 (gas cost increases)
• EIP 2930 (optional access lists)
• Account abstraction (perhaps a quick update; we're likely to be in a position for a fuller discussion next call)
• General discussion on the idea of combining some of the above EIPs and others that create a new transaction type, so we just create a single new transaction type that has a whole bunch of the features together. (HT @MicahZoltu)

[MicahZoltu]

Should we bundle EIPs 2711, 1559, and 2930 into a single monolithic EIP, or should we keep them separate?

If all 3 land in the same hard fork, overall development effort and cognitive load on client developers will be lower. However, the effort to implement any one of them individually will be higher (since you essentially have to implement them all at once).

All 3 EIPs are compatible with each other where 2711 and 2930 add optional fields to a transaction and 1559 changes the gas pricing mechanism. Once 1559 goes out we almost certainly will want to either update the spec for 2711 and 2930 (if they haven't gone live yet) or deprecate 2711 and 2930 transactions and create a new EIP for each with the integration of 1559 gas pricing.

I think the most important questions to answer are:

1. Do we think 2711, 1559, and 2930 will all land in the same hard fork?
2. Do we want to optimize for overall development costs (monolithic transaction type) or do we want to optimize for iterative/bite-sized change sets (separate EIPs).

[MadeofTin]

2711 and 2930 along with 2718 make sense to be in one.

2718 and 2930 a minimum to be considered for Berlin.

1559 will take longer and so should be in the fork after imo.

It would be nice to get 2718(plus one other transaction type) in for Berlin so not everything is changing at once.

[MadeofTin]

Rather than thinking about it as all in for Berlin. We can think of it as all in for YOLOv2, so the work for clients is bundled even though the decisions are not.

[MicahZoltu]

I definitely support 2718, 2711, 2930 in Berlin if others think that is realistic. I thought that Berlin was all but "feature frozen", so I haven't been pushing at all for that. If there is demand, I can draft a document (maybe an EIP, not sure if that makes sense here) that combines all 3 of the above into a single specification so it is easier for implementers to refer to a single thing.

[AlexeyAkhunov]

Please put the discussion about potentially removing gas refund. There is a reason to believe that unless we stop GasToken2 and CHI from working, we will never see low gas prices ever (as per discussion in eth1x channel on Discord)

[timbeiko]

I can give an update on EIP-1559 based on the last implementers' call @Souptacular

[Souptacular]

@AlexeyAkhunov @timbeiko Added!

[shamatar]

EIP-2046 can now go without dependency on EIP-2666 with this fix for Geth

[wjmelements]

@AlexeyAkhunov I can't find your discord server but my objections to your EIP and my proposed alternative are here. You haven't articulated your case that gas refunds pump gas price in any of the standard forums but I would like to voice my skepticism. Gas tokens reduce peak gas costs by increasing the effective block size under congestion, while offsetting long-term state growth.

As a major stakeholder I would be interested in a compensation plan if this went forward.

Edit: I have written up the alternative EIP

[villanuevawill]

Could we add a quick agenda item to briefly mention the AA EIP and AA DoS study released:

• Account abstraction EIP EIPs#2938
• https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937

We would like to formally propose the EIP as a larger agenda item for the subsequent all core devs. For this one we just want to mention these in preparation.

[Souptacular]

@villanuevawill Added! We may not have time to get to it, but we will try :)

[gcolvin]

There was confusion at Meeting 94 as to the state of our consensus on progPoW, which is under review here.. We once published a decision to deploy -- Meeting 81 -- disavowed that but did not publish our new decision two weeks later -- Meeting 82 -- and in the end Vitalik announced that we had decided to go with Ben DiFrancesco's compromise. We have yet to publish any decision that anyone can count on. I want to see actual discussion and at least rough consensus soon.

Meeting 81:

...
FJL: No, it's not that. It's not about hardfork announcement. It is more about the decision that the official decision is now for ProgPOW will happen and that doesn't really a hardfork announcement that's just an informational post.

James: And when it will happen, will be after this the third week. If we don't say when it will happen, I don't think it will happen. So having it be the third Wednesday after the BLS recompile is a way of saying, this is it, is happening, when it will happen
...

DECISIONS 81.5 Berlin would happen when the BLS pre-compile is ready, ProgPOW would happen the next third Wednesday after that.

Meeting 82:

...
Ameen Soleimani: ... The CoreDevs that have so far been trigger-happy with ProgPoW and have not accurately taken into account the risk of bugs. I no longer believe they are to be trusted...

... [downhill from here, IMHO] ...

Hudson Jameson: Thanks everyone for the stuff that has been said, I think there needs to be more discussion. We’ve made progress since the beginning of the meeting. For everyone that has just joined, there is agreement that ProgPow Isn’t going in any time soon (within the next 3 to 6 months). Greg Colvin was concerned about this “agreement” thinking it was still “on track”. Hudson, Fiji and James Hancock clarified that: “It was absolutely not going into a hard fork any time soon. Being accepted is very different from being scheduled.”

Hudson Jameson: As far as the core devs go: Where do you think we’ve come to? Martin (especially), Vitalik, Peter, Felix, Thomas

Felix Lange (fjl): We've come to the conclusion that the community really, really, really doesn't want it. And for me personally, this is a very strong sign. There is a technical argument to be made for ProgPOW. There is a social argument to be made against progPoW. If we cannot reach consensus on all sides about what the change should be, it cannot go in. I’m not willing to put in the change with so much community resistance, regardless of where it is coming from.

Hudson and fji: Community resistance is outside of the process, but it is important to listen to pushback.
...
Felix Lange I think that the decision as to whether or not ASIC resistance is important for Ethereum is purely a social decision with a lot of social factors. So it would definitely help to have more opinions on ASIC resistance from everyone. And that includes the much, much wider community.
...

DECISIONS 82 None published.

All Core Devs 2020 Apr 25 17:22
...

vbuterin: The primary issue is that large portions of the community have made it very clear that they don't want progpow
vbuterin: And that the compromise is that it gets deployed on a testnet and stands ready as deterrence
vbuterin: That seemed very clear to me and others I talked to during The Big Call ~6 weeks ago, and discussions before and after that
vbuterin: Ultimately we need to remember, the ethereum ecosystem doesn't serve the processes, the processes serve the ethereum ecosystem
...

DECISIONS None published.

[lightclient]

@MicahZoltu: Should we bundle EIPs 2711, 1559, and 2930 into a single monolithic EIP, or should we keep them separate?

IMO they should be evaluated separately. I wouldn't want to weight 1559 down with 2711.