Wrapped up another @ethereum #AllCoreDevs today. Covered the Goerli outage, Kiln updates, merge testing, beacon chain withdrawals and a few more misc. items π
Agenda: github.com/ethereum/pm/isβ¦
Stream:
Agenda: github.com/ethereum/pm/isβ¦
Stream:
https://twitter.com/TimBeiko/status/1489728988264026113
@ethereum Re: the stream, apologies but due to a zoom config issue, the first part of the discussion is missing the audio from everyone except me π
The notes will have a full transcript for that part of the call too.
@ethereum First on the call, we discussed the Goerli issue from overnight: a number of validators were down and the alterting software didn't catch it. On the call, the root cause of the issue hand't been found yet, but several teams were investigating.
@ethereum Nethermind's main signer was down and they were switching to a backup, Geth's signer was still up and so was Besu's. The issue seems to have been fixed (Goerli is back up!), and we should expect a proper post-mortem early next week.
@ethereum Next up, we discussed the latest progress on The Merge. A new devnet has been spun up with the clients who have implemented the latest spec changes, which you can see here: devnet4.themerge.dev
Note: the beacon chain explorer isn't working yet.
Note: the beacon chain explorer isn't working yet.
@ethereum When running the devnet through the transition, @vdWijden's miner was too powerful and it created competing terminal PoW blocks. This was our first time seeing this happen on a live network, and the devnet successfully finalized a chain π
https://twitter.com/parithosh_j/status/1494391673526312964
@ethereum @vdWijden Mikhail had a few tweets explaining exactly how the PoS forkchoice deals with multiple terminal PoW blocks:
https://twitter.com/mkalinin2/status/1494590871366479875
@ethereum @vdWijden The entire process of mining + gossiping the conflicting PoW blocks and then choosing which one to finalize on the post-merge chain happened in a few minutes.
@ethereum @vdWijden One thought by @dannyryan about this is that, like for the beacon chain launch, we should write down and make public what we expect to see happen during The Merge and what the potential edge cases, such as this one, are.
@ethereum @vdWijden @dannyryan Next up, we discussed the implementation status for the v2 spec of Kiln. Still a WIP for most client teams. Given that the v2 changes are additive and not consensus breaking, we'll still launch another devnet next week to run through the process again.
@ethereum @vdWijden @dannyryan We then had a discussion about one of the changes: the authentication between the tCL and EL clients. In short, the fact that all clients don't support authentication yet means we still need to keep the unauthenticated connection in parallel to test on devnets.
@ethereum @vdWijden @dannyryan This seems like the right thing to do, but we agreed that the non-authenticated ports need to be deprecated in clients by the time we fork existing networks.
@ethereum @vdWijden @dannyryan Another thing we discussed was updating the JSON RPC methods to better reflect various blocks' states post-merge. I had covered this in a blog post previously: blog.ethereum.org/2021/11/29/how⦠
@ethereum @vdWijden @dannyryan TL;DR: the merge changes the assumptions you can make about the likelihood of certain classes of blocks re-orging. While currently JSON RPC accepts the `latest` flag to return the block at the tip of the chain, it's to be expected that this block could be re-orged.
@ethereum @vdWijden @dannyryan Under PoS, we can pretty quickly get a "safe" block which we expect to not be re-orged under normal circumstances, so we'd like to update the block returned by `latest` to that "safe head" block given this is the default usage of the API.
@ethereum @vdWijden @dannyryan Applications could still get the very last block on the chain by using the "unsafe" flag instead.
@ethereum @vdWijden @dannyryan Similarly, under PoW we use a block confirmations to get high certainty that a block won't be re-orged. Under PoS, we can get an explicit confirmation: the finality threshold. We'll thus add a "finalized" flag to JSON RPC endpoints which will return the last finalized block.
@ethereum @vdWijden @dannyryan All of this is still TODO (and isn't a consensus-related change) but we're at the point of starting to look into it. One of the first steps here is to formalize the "safe head" algorithm for clients to use. Expect more updates on this in the next few weeks/months!
@ethereum @vdWijden @dannyryan We then had some naming discussions π! This was about the renaming of the DIFFICULTY opcode to RANDOM. I'll spare you all the back and forth (the livestream has it all π!), but, TL;DR, the RANDOM name could cause confusion.
@ethereum @vdWijden @dannyryan The value returned post-merge for this is pseudorandomly produced by the Beacon Chain RANDAO implementation, not "true randomness". The EIP's Security Consideration section explains this in detail: eips.ethereum.org/EIPS/eip-4399#β¦
@ethereum @vdWijden @dannyryan After some back and forth, and discussion about whether we could further improve this randomness value with VDFs in the future, we decided to rename the opcode to PREVRANDAO (no underscores in opcode names...!) to describe its current functionality more precisely.
@ethereum @vdWijden @dannyryan Then, we had the folks from @KurtosisTech join the call to share the work they've been doing to help our testing efforts. Kurtosis were one of the few teams that reached out after my calls for more testing help and they've been great to work with!
@ethereum @vdWijden @dannyryan @KurtosisTech I recommend watching the recording to see their full demo. In short, their tool allows you to spin up a multi-client merge testnet locally, and it works with every client which supports the latest specs.
@ethereum @vdWijden @dannyryan @KurtosisTech This is very useful for quickly running PoW -> PoS transitions locally and debugging both single and cross-client issues. They've found and helped debug several issues over the past couple months!
@ethereum @vdWijden @dannyryan @KurtosisTech There is also a fork monitor, transaction spammer, and grafana dashboard included as part of the module. You can dig into it more here: notes.ethereum.org/@ExXcnR0-SJGthβ¦
@ethereum @vdWijden @dannyryan @KurtosisTech We'll also have a breakout room session going into more depth next Friday, 14:00 UTC: github.com/ethereum/pm/isβ¦
@ethereum @vdWijden @dannyryan @KurtosisTech Next up, @ralexstokes and @dannyryan presented the first drafts of EIPs which will enable validators to withdraw their stakes from the Beacon Chain.
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes At a high level, two changes are needed: one to expose the Beacon Chain state root on the EL side, and another for the EL to process withdrawal receipts and validate them against that root. An EIP is live for the former: eips.ethereum.org/EIPS/eip-4788
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes After a brief overview, there was a lot of discussion on the call about how to best expose this in the block header. While it's easy to append things to the block header, it would break a lot of tooling/infra to change the format of existing fields.
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes This EIP thus proposes to repurpose the deprecated ommers-related fields to store the Beacon Chain state root information, keeping the same overall layout:
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes It's worth considering that we might want to eventually expose more CL information in the EL block headers, so there is a tradeoff to repurposing too many things. If you'd like to chime in on this discussion, I recommend the @EthMagicians thread: ethereum-magicians.org/t/eip-4788-beaβ¦
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes @EthMagicians Next up, @dannyryan gave a (verbal) overview of what the mechanism to track the withdrawals would look like. At a high level, we'll need a "withdrawal contract" on the EL.
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes @EthMagicians The exact mechanism by which the withdrawals get credited back on the EL is still TBD, there are many options of varying engineering and "supply accounting" complexity. Expect more discussions on this as Shanghai starts shaping up!
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes @EthMagicians Last up on the call, @alexberegszaszi covered EIP-4803, which proposes to cap the gas limit in a transaction to 2^63-1. This type of change, making explicit specific constraints in the protocol, was done before for other values and there was broad agreement to do it here too.
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes @EthMagicians @alexberegszaszi Because the value is huge, and much larger than a transaction could ever use, it doesn't require a hard fork to "activate". There was some debate about the specific constant to use for the cap, but general agreement towards having one.
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes @EthMagicians @alexberegszaszi And that was it! Next ACD scheduled for March 4, 14:00 UTC. See you then!
@ethereum @vdWijden @dannyryan @KurtosisTech @ralexstokes @EthMagicians @alexberegszaszi Good q by @superdavehodge: withdrawals from the beacon chain won't happen at The Merge, but in the fork after (Shanghai), so discussions/debates here don't affect the merge work. The Merge is very complex so we removed as much as we could from it.
https://twitter.com/superdavehodge/status/1494772771422969862
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
