We wrapped up #AllCoreDevs no. 115 a few hours ago.
Agenda: github.com/ethereum/pm/isβ¦
Stream:
Overview of the call below ππ»
Agenda: github.com/ethereum/pm/isβ¦
Stream:
Overview of the call below ππ»
https://twitter.com/TimBeiko/status/1393239609484529669
We started with a lot of action as @mhswende identified an issue in EIP-1559 yesterday where the new fields introduced in transactions (maxFee & maxPriorityFee) did not have an explicit cap. This meant that an attacker could create arbitrarily large transactions.
Prior to 1559, this is not possible because if you want to create a transaction with a huge gas price, you actually _need_ to have that amount of ETH, and if your txn is included, you will _pay_ that amount.
Because the fields in 1559 are maximums, you could abuse this, not actually pay those huge gas values, and spam the network.
Alongside this, some clients already had checks to prevent these fields from being larger than 2^256, but because this was not in the spec explicitly, not all of them did. This meant that one of those bad blocks could not only DoS the mempool, but also split the chain.
Luckily, the fix for this is quite simple, as suggested by Martin here: github.com/ethereum/pm/is⦠
Basically, we add four checks to EIP-1559: the first two check that the maxFee and maxPriorityFee are < 2^256. This is what some of the clients already did.
The third checks that the maxFee is larger or equal than the maxPriorityFee. This intuitively makes sense: the total fee paid should be larger or equal than the portion of it that goes to the miner. Again, some clients already implicitly checked this.
Lastly, we check that a transaction sender's balace is larger than their maxFee times their gas used. This ensure that an account actually has the funds to pay for its worst-case maxFee.
We had a lot of back and forth on the call about which of these should be included in the consensus rules explicitly, as only the two first "< 2^256" ones are strictly necessary, but we decided to include all four for clarity and caution.
The fourth was the most contentious as there may be some weird edge-cases where you could want to set a maxFee higher than your balance if you think the address' balance will somehow be incremented before the txn is executed.
After some discussion, we ultimately decided it was safer to put it in now, and if someone has a strong rationale for not having this check, we could remove it in a future network upgrade quite easily.
While this change is simple, it does mean we will need to perform some more testing once clients have implemented it.
At first, we thought we could maybe keep using Baikal (if no one had triggered that specific edge case), but it seems that while load-testing the network, some transactions did break the new checks.
This means we'll need to spin up a new devnet, Calaveras π, on which we'll deploy the newest changes to 1559. The spec is available here: github.com/ethereum/eth1.β¦
We expect it to be live late this weekend or early next week.
We expect it to be live late this weekend or early next week.
When discussing Baikal, we also went over some issues that teams have encountered in the transaction pool during the stress test for the network. Geth, Nethermind and Erigon are still working on some tweaks to the transaction pool management.
Given this, we agreed that it would be unsafe to fork the testnets in ~10 days. We will use the next two weeks to update tests, stand up and load-test Calaveras and finalize the txn pool implementations.
On the next ACD, assuming all this went well, we'll look at setting new testnet fork blocks.
Client teams said they should be able to get a release out with the testnet blocks a couple days after ACD, and we want to give ~1 week heads up before forking, so realistically the first testnet could fork ~10 days after the next ACD. Again, this is assuming nothing goes wrong!
Once we fork on the testnet, we will also try and have a stress test on it. Thanks to @hudsonjameson I now have the Ropsten ETH to fund it π³
Assuming the testnet forks smoothly, we'll then set a fork block for mainnet.
Lastly, after some feedback on the 1559 Wallets call this week, @trent_vanepps has organized another call next week to discuss the impact on gas price oracles (e.g. EthGasStation, GasNow, etc.). It is next Friday, 14:00 UTC, agenda here: github.com/ethereum/pm/isβ¦
Outside of London, we also had two discussion topics. First was an idea by @realLedgerwatch to better deal with worst-case transactions w.r.t. gas execution. See his full post here: ethresear.ch/t/a-third-way-β¦
(To be clear, Alexey's post is his comment, not the top-level EthResearch post!)
In short, Alexey explained on the call that right now our gas limit is mostly set to avoid "execution bombs", i.e. transactions that, when executed, will consume much more computation than their relative gas price, which can lead to blocks taking too long to execute.
This problem was the motivation behind raising the gas costs in Berlin with EIP-2929.
Alexey's proposal is that we could perhaps separate the transaction pool from the clients further and have it try to "diffuse" those execution bombs before sending them to the client.
If we had that sort of "guard", then perhaps we could increase the gas limit given that we would now be optimizing for the ~average case rather than the worst case.
There was some pushback on his idea (I recommend the livestream for details!), but people agreed this could be a promising area of research. We will create a discord channel in the Eth R&D server to discuss further.
Lastly, @pipermerriam and a co-author (can't find the handle!) came on the call to introduce EIP-3584 (github.com/ethereum/EIPs/β¦). The idea of the EIP would be to add access lists to blocks, similarly to how EIP-2930 introduced them for transactions.
Doing so could enable optimizations in how blocks are processed, and would be a good building block for stateless execution further down the line.
Even though the access lists proposed here serve a similar function to the 2930 ones, there are some difference which complicate things a bit. These subtleties were discussed on the call, up until we ran out of time.
We'll be continuing these discussions in the Eth R&D channel, and under the ethresearch post associated to the EIP: ethresear.ch/t/block-accessβ¦
And that was it! The next two weeks are (hopefully!) the last big push we need to get the London testnets ready.
If you are a project who will be affected by 1559, gas refunds, or other changes included, now is the time to review the spec and reach out!
If you are a project who will be affected by 1559, gas refunds, or other changes included, now is the time to review the spec and reach out!
Next call is scheduled for June 11th, 14:00 UTC. Agenda is up here: github.com/ethereum/pm/isβ¦
Some questions in my mentions! Will try and answer a few by QT-ing them below ππ»
This is a pretty critical issue, given it could lead to a chainsplit, but luckily it has a very simple fix (4 checks), which at least half of the clients already implemented.
https://twitter.com/ricburton/status/1398330564340457473
The fix basically makes explicit some behavior that was "intuitively right" in the spec. This means that now the issue could not be exploited accidentally or maliciously to cause a chain split.
We don't have a date for the testnets yet, but I suspect that yes, the first testnet could fork around June 20-something. *If* we choose the blocks on the next ACD, I think these could be good candidates: docs.google.com/spreadsheets/dβ¦
https://twitter.com/Martin1ethereum/status/1398334265872596996
This is just my opinion, though, definitely not official!
Again, that would be my guess and it works with what I have in the spreadsheet above, but it is no guarantee.
For example, if we found another bug, we would obviously prefer delaying another 2 weeks than risk forking mainnet.
For example, if we found another bug, we would obviously prefer delaying another 2 weeks than risk forking mainnet.
https://twitter.com/halfinney22/status/1398334897639477248
It is worth noting though that the difficulty bomb puts an upper bound on how much we can delay things. Some time in August, IIRC, we will start to see it go off.
Another question:
https://twitter.com/halfinney22/status/1398343380141101056
Longer answer:
https://twitter.com/TimBeiko/status/1398346261393068032
First, we want to wait until London to do any further changes because we'll already get a 2x bump in worst-case gas limit after 1559.
https://twitter.com/coinfreakgr/status/1398352256077119488
As for increasing it further once things are stable, the concerns are basically the same as right now. Vitalik had summarized them well here: notes.ethereum.org/@vbuterin/eip_β¦
This is the relevant section:
There are two ways we can fundamentally address these: better client architecture (e.g. what @ErigonEth is working on, what Geth introduced with snapshots, etc.), or having sustainable state management approaches, which Vitalik also wrote about recently: vitalik.ca/general/2021/0β¦
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
