.@ethereum #AllCoreDevs starting in ~5 minutes with a PACKED agenda (doubt we get through it all π
)
Last minute Berlin changes π©πͺ, and a slew of potential London EIPs π¬π§, including EIP-1559 π₯
Agenda: github.com/ethereum/pm#acβ¦
Stream:
πππ
Last minute Berlin changes π©πͺ, and a slew of potential London EIPs π¬π§, including EIP-1559 π₯
Agenda: github.com/ethereum/pm#acβ¦
Stream:
πππ
https://twitter.com/TimBeiko/status/1362787905433866245
First up, @hudsonjameson announces this is the last call he'll be facilitating. Starting next call, I'll be facilitating them ππ»
Hudson will still be available to help out, and will be working on other initiatives at the EF π¦
Hudson will still be available to help out, and will be working on other initiatives at the EF π¦
Next, is a discussion about whether we should keep EIP-2315 in Berlin, which was kicked off by a tweet from earlier this week:
@lightclients opened an issue questioning whether we should keep it in based on that feedback: github.com/ethereum/pm/isβ¦
https://twitter.com/ethchris/status/1366436964153651204?s=20
@lightclients opened an issue questioning whether we should keep it in based on that feedback: github.com/ethereum/pm/isβ¦
In short, the EIP, which is a "more minimal" version of a previous EIP, 615, may be "too minimal" to provide much value.
One major concern that was brought up this week is that removing something so close to the upgrade going live could create a bad precedent (e.g. people can FUD EIPs at the 11th hour). OTOH, leaving something without much usefulness in because of The Processβ’οΈ is also a precedent.
@realLedgerwatch has a good comment about this, from the issue:
Over the past few days, it first seemed as though the EIP would be useful to Vyper. That seemed to convince core developers to keep it in, but over the past ~24h, it seems like even they may not benefit from it (cc: @fubuloubu, hope i got that right!)
@ethchris on the call says that it was not clear to him what the main goal of the EIP was. It is not a negative per se for Solidity, but the EIP does add complexity to the EVM, which "ripples out" to all tooling interacting with it.
Another point is that once we ship the EIP, we will have to deal with it "forever", even if we remove it in a future upgrade, because we'll always need to be able to process those blocks.
With regards to client implementations, @nethermindeth has a release with EIP-2315, but will need to re-release anyways. For them, if the EIP is not useful to Vyper, they'd rather not include it.
@OpenEthereumOrg has a release candidate with 2315, but it is easy to remove it. If there is no user for 2315, they would rather remove it and wait.
#HyperledgerBesu has a release with 2315, and doesn't have a strong opinion about whether to keep or remove the EIP from Berlin.
@go_ethereum explicitly excluded the Berlin from their last release. If we're keeping Berlin as is, they could release today, but if we remove 2315, they would do one early next week.
@peter_szilagyi says they Geth will accept whatever the outcome of this call re: 2315. He adds that on a personal level, it's very bad we're even considering removing something now. A lot of people have put a lot of work into this, and removing their EIP is terrible for them.
Given all of this, it seems like we're leaning towards removing 2315 from Berlin π©πͺ.
There were a bunch of issues in the process of accepting 2315. This is something we'll be looking into more deeply soon. @lightclients documented them well here (github.com/ethereum/pm/isβ¦):
@shemnon +1s Peter's comment about the impact on future community members' contributions. This will likely make people less willing to contribute to Ethereum.
Lots of more comments about the process and what went right/wrong. Won't try and summarize them all here, and strongly recommend the livestream for people interested in the details πΊ
One quick comment by Vitalik: we need to get better at getting feedback from the community on these changes earlier on.
We already have a plan for this in the works... more on that soon π
We already have a plan for this in the works... more on that soon π
@peter_szilagyi adds that removing an EIP is somewhat uncharted territory, and does add some technical risk.
So, we agreed to remove 2315 from Berlin β
Next up, the question is what do we do about the Berlin schedule? Ropsten was scheduled to fork in ~5 days, which is far too close to have a full testing + release + announcement cycle.
One proposal by @q9fmz is that we could keep the Ropsten date, and have client teams start miners on Ropsten, which would ensure that we get maximum testnet data.
@shemnon says he strongly favours anything that keeps the mainnet block fixed.
Geth and Besu can definitely run miners on Ropsten, and OpenEthereum may be able to do so. There are others who can also try and assist to make sure we've got enough eyes on the chain.
π If you are using Ropsten, please keep an eye out for new client releases coming out today/Monday π
As soon as the client releases are out, we'll have a proper blog announcement for Berlin that will be shared by several projects in the community. Expect it Monday/Tuesday!
Again, here's the schedule for Berlin: github.com/ethereum/eth1.β¦
Next up is London EIPs, and I'm up!
I made a quick case for 1559, more details in the issue I opened for the call: github.com/ethereum/pm/isβ¦
First comment by @peter_szilagyi is that he would like to do EIP-1559 in London if it is coupled with a refund removal EIP, because refunds can lead to blocks being 2x the gas limit, which 1559 can also do, which would result in a potential max increase of 4x.
Geth says that even proposals that slowly phase out refunds would be fine, given the performance improvements they've made and the gas repricings coming in Berlin.
@hudsonjameson is summarizing the call we had with @EthCatHerders about 1559 a few weeks ago.
@tkstanczak says we should minimize what goes into London to make sure we get 1559 out. For other ideas, we could potentially start discussing the next fork, Shanghai.
And we're now discussing the pros/cons of bundling 1559 with the ice age pushback βοΈ See the livestream for the nuance here πΊ
We're in agreement about 1559 and a difficulty bomb pushback going into London π₯π
One small technical details is whether we should also add an opcde which returns the BASE FEE (eips.ethereum.org/EIPS/eip-3198
). There is some more investigating we need to do on it, so we'll bring it up on the next call.
). There is some more investigating we need to do on it, so we'll bring it up on the next call.
Last on the call is the discussion about how we go about removing refunds. @VitalikButerin had a proposal to remove them altogether (github.com/ethereum/pm/isβ¦), and there are now two counter-proposals:
- github.com/ethereum/pm/isβ¦
- github.com/ethereum/pm/isβ¦
- github.com/ethereum/pm/isβ¦
- github.com/ethereum/pm/isβ¦
The author of the counter, William Morris, is on the call giving a quick overview of the proposal. We ran out of time, but will discuss in more depth on the next call.
And that was it! See you on March 19th for the next ACD πππ»
And that was it! See you on March 19th for the next ACD πππ»
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
