First, the 1559 resources page is now linked right at the top π
Second: we found a few bugs in our large state testnet. We're in the process of fixing them and restarting the network πβ³
Third: now that EIP-2718 is confirmed for Berlin, we're updating the 1559 spec to work with it. We've also drafted an EIP to add a BASE FEE opcode to 1559, which will make a bunch of smart contract use cases smoother π
Fourth, @VitalikButerin shared his thoughts on the DoS risks of 1559, and why they may not be as bad as they seem π€π»
Fifth, @adietrichs has basically solved out transaction pool issues πβ
Sixth, some more R&D simulations by @barnabemonnot and the @nethermindeth folks, looking at the transition from legacy to 1559-style transactions and potential BASE FEE manipulation ππ
And, last but not least, some updates on the recent pushback from miners' we've seen with regards to 1559 β
And, right as I pressed Publish, @ralexstokes shared a great article about mining incentives alignment under 1559:
This is the equivalent of the previous "Hardfork Meta" EIPs that we had for previous hard forks.
Where we're at right now is that we need one more PR merged into Geth for EIP-2718/2930, then we can set up YOLOv3 and start looking at blocks for testnets.
First on the call, @adietrichs gave an update on his work about transaction pool management. His latest writeup is available here: hackmd.io/@adietrichs/15β¦
The document is quite short, and worth reading, but here are the main takeaways with regards to mining β
Nethermind going first: EIP-2929 now passes all tests, and they are waiting for some final specification decisions for EIP-2930 & 2718. Everything is ready ππ»
Besu: everything is implemented, and the team is working on testing for 2930 β
OpenEthereum: everything should be ready π
Geth: EIP-2930/2718 is still remaining, and then there are still a few small issues to fix. @lightclients is leading the implementation, and says it should be up to spec. Going into the details on the call now about the final tweaks πΊ
Here's an attempt at explaining the ETH supply discrepancy that @pierre_rochard & others have pointed out.
TL;DR: because Ethereum doesn't just have ETH (it also has contracts), instead of tracking supply each block, both the tokens and contracts are tracked, a.k.a. the "state"
Obviously, because this state is large, it's not literally part of each block, instead we store it in a tree and just keep the root node ("state root"). Every time an account or contract, which is stored in a leaf of that tree, changes, it change its entire branch, incl. the root