Thread by @TimBeiko

We wrapped up another @Etherum #AllCoreDevs earlier, covering all things Merge as well as mev-boost and censorship resistance at the protocol level. This was a much less "procedural" call than usual, and touched on a lot of the "softer" governance questions around Ethereum.

https://twitter.com/TimBeiko/status/1555254767756029952

@Etherum If you have the time (we even ended early!) I strongly recommend watching the whole recording. The Merge stuff was just ~20 mins, and then it was much more of a free flowing discussion.

@Etherum It's very hard to summarise and keep the nuance, and to not put words in people's mouth, I'll err on the side of brevity.

Agenda is here: github.com/ethereum/pm/is…
Full recording:

@Etherum One last caveat before I start - any errors/misrepresentations here are fully on me. If in doubt, please cross-check with the recording. And, with that said, let's get into it 👇

@Etherum First thing on the agenda was Sepolia's post-merge upgrade. It's scheduled for block 1735371, which was originally supposed to hit yesterday. Due to some validators being offline, it's now expected around Aug 21st. You can track it here: sepolia.etherscan.io/block/countdow…

@Etherum So, last call, if you haven't upgraded your Sepolia node, you have a the weekend to do so! blog.ethereum.org/2022/08/03/sep…

@Etherum Then, we got an update on our 11th Mainnet Shadow Fork (yes, they are still happening!). We had 34/35 nodes make it through The Merge without issues, with the 1/35 simply not having synced!

@Etherum Post-merge, we saw two known issues, one with Erigon producing a bad block which had happened on Goerli before, and one which had to do with Nethermind's block production when interacting with certain client pairs.

@Etherum Both of these have fixes in progress, and we'll test them on future shadow forks once merged.

@Etherum We then discussed the TTD we set on the CL call last week. Although there have been some minor fluctuations in hashrate, the ETA for 58750000000000000000000 is still ~Sept 15, so we agreed to keep it. In short, TTD confirmed ✅! You can track the ETA at bordel.wtf

@Etherum At this point, the only thing that could cause the TTD to change would be a massive drop in hashrate once Bellatrix is hit. If, for example, we saw that 58750000000000000000000 would be hit several weeks past Sep 15th, we could coordinate a TTD override.

@Etherum While this is unlikely, it's also a pretty easy process: clients just update a value in their releases or users simply pass the new TTD in as a flag, like we did for Ropsten: blog.ethereum.org/2022/06/03/rop…

@Etherum Next up, we discussed the deprecation of the Kiln testnet, which had been launched for users to test post-merge Ethereum well before Goerli/Ropsten/Sepolia were scheduled to fork.

@Etherum We had announced we'd shut it down "at the mainnet merge" (blog.ethereum.org/2022/06/21/tes…) and confirmed we'll do so around when Bellatrix is activated on mainnet, on Sept 6. The network has barely any transactions going on it, and 3 testnets now offer a post-merge environment.

@Etherum And that was it for the merge-related contents. Next up on the call were two topics put on the agenda by @MicahZoltu: potential censorship issues with mev-boost relays, and client developers' general stance towards punishing censoring validators on the network.

@Etherum @MicahZoltu In the spirit of 'not putting words in people's mouths', I encourage you to read Micah's summaries of the issues on the agenda: github.com/ethereum/pm/is…

@Etherum @MicahZoltu To kick things off on the call, Micah, after a brief summary of the issue, framed the question whether client developers want to launch "with" MEV-boost, despite the fact that censorship at the relay level is possible or likely?

@Etherum @MicahZoltu One clarification on the "with" above: currently CL clients do *not* bundle MEV-boost by default. They expose an API, the builder API (github.com/ethereum/build…), which MEV-boost can connect to.

@Etherum @MicahZoltu Similarly, MEV-boost can accommodate multiple relays. While Flashbots, the main developer of MEV-boost, has some restrictions in their relay/API, they have now open sourced the codebase

https://twitter.com/hasufl/status/1559908331145265156

@Etherum @MicahZoltu Again, strongly recommend watching the discussion here for all the nuance, but here are some of the comments during the discussion.

@Etherum @MicahZoltu First, @dankrad mentioned that there have previously been sanctioned Ethereum addresses and wasn't convinced the situation had materially changed. He expected a majority of validators to not use censoring relays.

@Etherum @MicahZoltu @dankrad Then, @VitalikButerin highlighted that "censorship" can mean two different things: not including transactions in one's block or refusing to attest/follow a chain which includes transactions you do not like.

@Etherum @MicahZoltu @dankrad @VitalikButerin The first case is one where, for full censorship to happen, you effectively need 100% of the stake to censor in unison. Otherwise, a non-censoring validator will include the transaction eventually.

@Etherum @MicahZoltu @dankrad @VitalikButerin For ex, if 80% refuse to include a transaction, in practice it would be included within 5 blocks on average. 90% -> 10 blocks, and so on.

@Etherum @MicahZoltu @dankrad @VitalikButerin So, this requires a far higher degree of coordination than refusing to extend a chain which contains transactions you dislike, where 51% of the stake could effectively make that censored chain "canonical".

@Etherum @MicahZoltu @dankrad @VitalikButerin On the other hand, this second approach requires much more custom software - it is effectively a soft/hard fork where you add some censoring conditions as part of your block validity rules. To Vitalik's knowledge, this software isn't being developed now.

@Etherum @MicahZoltu @dankrad @VitalikButerin Then, Mamy highlighted the power of the community to also address these concerns. In the short time since the conversation started around censoring relays, many actors have stepped up to say they would offer various kinds of differentiated relays.

@Etherum @MicahZoltu @dankrad @VitalikButerin After @dannyryan commented on the idea of CL teams removing their support for the Builder API. This would simply lead to a lot more forked clients (like mev-geth in PoW) and be a net negative: the mev market wouldn't change, but it would be run with less visible software

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan .@URozmej shared his concern that mev-boost is slightly worse than the current status quo wrt censorship because validators accepts full blocks from relays, rather than transaction bundles in mev-geth, removing the ability to add more transactions to the block.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej .@thegostep clarified that this is because otherwise validators could steal MEV from searchers submitting bundles. AIUI, in mev-geth this doesn't happen because Flashbots has direct relationships with the various mining pools, and could cut their access if they defect.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep The tradeoff with mev-boost is that in order to serve a much larger number of validators, rather than a handful of known pool operators, the relay has to send full blocks rather than a bundle to include within a block.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep That said, @thegostep added that there are designs being explored to allow validators to append transactions to the end of blocks. If you can prove that transactions are only appended, then there is no risk of the bundle being front-run by the block proposer, as it will run first

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep Going back to @MicahZoltu's original request, he asked whether client teams would be comfortable asking their users to not run relays which censor specific transactions.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep A few of them emphasised that, ideally, they'd prefer if users just ran the "vanilla" client rather than also having mev-boost at all. @vdWijden said he tries to convince users to run geth standalone.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain also added that mev-boost does increase block proposal latency, so it's not fully without technical risks to validators. There were a few more comments on the call, again, recommend the recording for the full assortment 😁

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain Next up was the broader discussion around censorship resistance, and how to react in the case of such an attack on the network. Here, Micah's initial ask was whether client teams would commit to, if the time comes, write and release software that penalises such an attacker.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain He empathised an important distinction: the most client teams can do is write+release that software and advocate users run it. Client teams don't run all the nodes, so activating such a software upgrade is very much in the hands of the community at the end of the day.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain There was a question about whether penalising an attacker to the protocol effectively amounted to "censoring the censor". @adietrichs explained that it was more about reacting to attacks that can't be identified in protocol.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs With PoS, we can already penalise validators who commit certain faults, as long as we can identify them. For example, if they are offline or refuse to attest, validators face an inactivity penalty. Similarly, if they attest to conflicting histories, they can get slashed.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs That said, there are certain things that can't be identified _directly_ in the protocol. The clearest example is a portion of validators colluding to frequently re-org the chain. This isn't just about censorship, there are also economic attacks, time bandit attacks, which do this

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs The challenge with these re-org based scenarios is that irregular, short range reorgs are expected, and part of the chain operating normally. It's only with an 'outside view' of the network that you can identify systemic patterns on this front.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs This is why such an attack can't be resolved without intervention. That said, Ansgar wasn't convinced whether it was net good or net bad to have software available to counter such attacks already written.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs Then, there were some questions about how long it would take such an attacker to exit their stake. Given the design of the withdrawal queue, and the stake size required to execute these these types of attacks (>33%), it would take months for an attacker to fully withdraw.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs Then @tkstanczak shared that ideally he would prefer to see responses to these things happen at the social, rather than protocol level. He gave the example of how during the China mining ban, mining operators literally moved their machines across the ocean to keep operating.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak Again, Angar disagreed here saying that re-org attacks are the one exception it would be valuable to coordinate a protocol-level response to.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak At that point, it seemed unlikely we'd reach consensus around Micah's original ask, of getting client teams to make a strong commitment towards a course of action in this hypothetical.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak .@vdWijden highlighted that while it's very hard to get teams/orgs to commit, this is very much a case where individuals' personal voices play a very strong role.

He said that censorship resistance was the hill he'd personally die on and walk away from Ethereum over

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak .@mhswende agreed with Marius on both fronts: individuals are better suited to state their preferences here than teams, and he also strongly values censorship resistance.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende My personal opinion here is also that individuals' positions are the crux of what matters in such a debate. That said, I recognise that live, recorded, "on-the-spot" calls aren't the medium everyone wants to use to share their PoV on such an important topic.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende Definitely didn't want to pressure everyone into "taking a stance" publicly right then and there 😅

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende And, to conclude the conversation, @jcksie highlighted that our governance system is very much optimised to address "urgent" issues, and so it's hard to get a strong reaction to hypotheticals. That said, he felt confident that if/when threats arise, we could handle them.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende @jcksie And we left it at that! I was very happy that this entire conversation on a topic where emotions run high was so civil. Many thanks to everyone who engaged respectfully!

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende @jcksie To conclude the call, we had two quick announcements: first, with the mainnet TTD set, EIP-3675 and 4399 have been moved to Last Call. They will be moved to 'Final' once The Merge is live on mainnet.

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende @jcksie Second, I'll be away for the next ACD. The call is still on for Sept 1, 14:00 UTC, but @dannyryan will be facilitating rather than me 😁

Please be nice to him, and I'll be back for the Sep 15th call (and Bellatrix's mainnet activation before that!!) 👋

@Etherum @MicahZoltu @dankrad @VitalikButerin @dannyryan @URozmej @thegostep @vdWijden @terencechain @adietrichs @tkstanczak @mhswende @jcksie Some clarifications re: relays by @foldfinance

https://twitter.com/foldfinance/status/1560354284310372352