-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ethereum Core Devs Meeting 95 Agenda #203
Comments
|
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:
|
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. |
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. |
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. |
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) |
I can give an update on EIP-1559 based on the last implementers' call @Souptacular |
@AlexeyAkhunov @timbeiko Added! |
EIP-2046 can now go without dependency on EIP-2666 with this fix for Geth |
@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 |
Could we add a quick agenda item to briefly mention the AA EIP and AA DoS study released:
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. |
@villanuevawill Added! We may not have time to get to it, but we will try :) |
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.
DECISIONS 81.5 Berlin would happen when the BLS pre-compile is ready, ProgPOW would happen the next third Wednesday after that.
DECISIONS 82 None published. All Core Devs 2020 Apr 25 17:22
DECISIONS None published. |
IMO they should be evaluated separately. I wouldn't want to weight 1559 down with 2711. |
Disagree, options like that should exist until real on-chain solutions are developed, blaming 3rd parties is immature. There's already private ETH sidechains which are fully solvent and operational without Gas fees for example. |
Does anyone notice the ASIC risky for ethash? INNOSILICON offers new A10pro+ miner which has params: 720MH / 6G graphics memory / 1300w, and it will enter the market in Dec. with around 20T total hashrate at least. So I am worry about the process of EIP-1057 and the chance for activating ProgPOW oneday |
Closing for the new agenda: #206. |
Ethereum Core Devs Meeting 95 Agenda
Agenda
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.
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.
Next call: September 17th, 2020 14:00 UTC
The text was updated successfully, but these errors were encountered: