NC

@benjaminion_xyz @ethereumfndn Need annotated spec for ePBS 🙏

I left paid work almost a year ago saying that only something spectacular would drag me out of retirement. Well, it happened - I am now with @ethereumfndn helping to shepherd fast finality to Mainnet. It's going to be quite the journey, but I am very excited! 🚀

@sina_mahmoodi eof is rolling in the coffin

It’s not a question coz the answer’s YES on.soundcloud.com/SlcqdoFqg9Tbid…

@jih2nn Following cadence shows Ethereum can ship things fast and effectively. But showing to who? The community right? But community wants focil

We all want the best for Ethereum. The opinions both for and against shipping FOCIL in Glamsterdam make sense in their own ways. FOCIL allows Ethereum to provide censorship resistance at the protocol level, which underpins Ethereum as a credibly neutral layer. However, the later we try to ship FOCIL, the more difficult it will become. The community has strongly signaled their preferences for FOCIL, and people have been working on FOCIL in a bottom-up fashion and will continue to do so. FOCIL adds complexity and delays the fork, repeating the same mistake made in Pectra, but we want smoother fork cadence. Developing ePBS and FOCIL together is more complex than developing 6s and FOCIL (on top of running ePBS). FOCIL has lower priority compared to other scaling features. You're not wrong. But you can't have both. What do you think is best for Ethereum? I'm of the opinion that we should go for FOCIL in Glamsterdam. I'm in favor of having forks that add more value. Good things take time. Not everyone agrees with the "two forks in a year" meme, at least in my filter bubble. The argument that we can delay FOCIL because we would have 6s and FOCIL in H* is a kind of make-believe. We do not know what we would ship in H* and significant features other than 6s are also being cooked for H*. That being said, having various people weighing in is one of the strengths of Ethereum. We invited people to voice their opinions in the last FOCIL breakout: #issuecomment-3501249470" target="_blank" rel="nofollow noopener">github.com/ethereum/pm/is… Please consider voicing your opinion, either it be positive or negative: ethereum-magicians.org/t/community-fe…

@nero_eth When we do H* scoping, will we also be saying having focil with 6s slot is too complex to ship safely on time, and that it will still matter in another 6 months?

Glamsterdam is already a big fork with ePBS and BALs. Adding FOCIL now risks making it too complex to ship safely and on time. We’ve proven this year that Ethereum can move fast and responsibly, and we should keep that momentum by keeping forks focused and testable. FOCIL is a strong, lasting idea that will still matter in six months. Giving ePBS the focus it needs is how we deliver a solid, stable upgrade.

@potuz_eth @barnabemonnot Yea, and when we are doing H fork scoping, we'll be like let's focus on 6s slot, and focil will add complexity. We do not get to enjoy the massive benefits of 6s slot until much later in 2027

@barnabemonnot Well, afaik Prysm was the only client with all implementations at least as a POC a few months ago (ePBS, 6 seconds and FOCIL). I trust we have a good understanding of the complexity here

While this is difficult to appreciate from the outside, a major decision is at stake behind the Forkcast rankings published over the last week: Adding FOCIL to Glamsterdam or not. In my view, it would be a short-sighted decision to add FOCIL, either as a definite commitment and even more so as a conditional one (“we’ll add it to the scope and see if we can ship it”). Were no lessons learned from Pectra? The headliner process was supposed to offer ACD a format to keep the fork scope manageable. It was already a process error to keep FOCIL in consideration after it was turned down as Glamsterdam’s CL headliner. Now ACD intends to add months of delay and a complex (even if well-understood) feature on top of ePBS, itself already a significantly complex change to the block construction pipeline. This is not about the merits of FOCIL. People know well its importance and the necessity of a mechanism like FOCIL to ensure inclusion in a world of provers and high scale. Including FOCIL later is fine, and in my view FOCIL + 6 second slots for H* is a very attractive option, that we should be working towards as ePBS-only Glamsterdam approaches deployment. Credible estimates give FOCIL + 6s slots H* a possible deployment in early 2027, while ePBS + FOCIL in Glamsterdam would possibly delay 6sec slots-only H* to the middle of 2027. This is at least 4 months of delay to ship the same package of things! This should tell you everything about the compounding testing and deployment complexity of ePBS + FOCIL. In addition, we do not get to enjoy the massive scaling benefits of ePBS + BALs until much later in 2026 too. This is an opportunity cost that is too often discounted. The ability to plan and make forward commitments on future forks is increased if ACD is able to protect itself from append-only decisions while increasing its cadence of forks. The positive flywheel disappears if we fail to do this, and in my view this simply does not serve our values or the interests of our community over the long run. More discussions are expected on this Thursday’s ACD.

Our next chapter: Transitioning from a pure JS client focused on browser compatibility to a performance-first, hybrid @JavaScript + @ziglang architecture. TL;DR: We're rewriting core modules in Zig and switching to @bunjavascript as our primary runtime: blog.chainsafe.io/lodestar-zig-a…

the eth core devs don’t tweet a lot about just how hard the work that they do is so let’s talk about it: 1. every line of code they merge can move more money than most banks process in a quarter. there is no staging server for that. 2. they swap consensus logic for a 400B + dollar economy without scheduling downtime. ever. 3. they coordinate hundreds of researchers, auditors, and client teams across time zones, cultures, and philosophies, yet ship like a single mind. 4. they do it all in public, with every decision dissected by the loudest peanut gallery on the internet, and still keep the vibe collaborative. 5. they design for attackers who have nine figure incentives and infinite patience. then they sleep anyway. 6. they keep six independent clients in perfect sync so the same block lives at the same height for every node in the world. 7. they turn bleeding edge research into production code while preserving backwards compatibility for machines that went online before defi even had a name. 8. they debug issues that only happen once a year on a single archive node because someone somewhere will rely on that edge case. 9. they write cryptography that must stay unbroken for decades while the math itself evolves beneath their feet. 10.when the upgrade lands smooth the outside world shrugs. inside ethereum we know it was a minor miracle. every successful fork proves that decentralized coordination can outperform the world’s best hierarchies and shows that open internet capital markets are now the default. thank you, truly. we owe you everything.

Let there be Prysm <> Lodestar FOCIL interop. Kudos for @terencechain @ensi321 @nicoflaig @parithosh_j @_pk910_ 🎉🎉🎉

We all know the risks of developing web3 using web2 tooling. Although we seemingly aren't ready to just start developing web3 on web3 yet, we expose ourselves to these kinds of risks. Any devs, including core devs, are still privy to the ToS of an US company, who can cancel you.

@eawosikaa @gakonst @ErigonEth Lodestar did publish a blog post blog.chainsafe.io/lodestar-propo… when ACDC asked for client team's opinion

@terencechain @potuz_eth @remy_roy @philngo_ @superphiz @nixorokish @sproulM_ @jcksie Thought about this a little bit. When ePBS eventually comes, we will have this flag sooner or later. So I'm cool with adding this flag now

@potuz_eth @remy_roy @philngo_ @superphiz @nixorokish @sproulM_ @jcksie I'm not sure the consensus clients have min bid implemented. That's only on mev-boost. We should implement though github.com/prysmaticlabs/…

Interesting debate here about whether or not it makes sense for client teams to set defaults for the benefit of protocol health or is that not "neutral"? @superphiz @nixorokish @remy_roy @potuz_eth @sproulM_ @terencechain @jcksie

@terencechain @potuz_eth @remy_roy @philngo_ @superphiz @nixorokish @sproulM_ @jcksie So it's not really about having this min-bid feature on client. Because if the user want to set a min-bid, they could've just set it in MEV-boost. Is it more about us client teams having the power to determine and set a default min-bid value in case the user doesn't set one?

@vdWijden I do like the free market approach puts censoring builders at a disadvantage in the builder market. Sounds capitalism

I wrote a quick post about my view on Inclusion Lists mariusvanderwijden.github.io/blog/2024/01/1…

🔧Exciting news, I've undergone an upgrade! Big thanks to @mikeneuder, @icebearhww, and the @EthResearch team for providing me with a new integration path. Moving forward, I'll exclusively share recently created posts and won't repost older topics with new comments. 🔗

Staking with geth carries SIGNIFICANTLY higher risks than running any other execution client! Not just for the network but for YOUR STAKE: 🧵 I'm glad to see this post from @dankrad getting attention again: dankradfeist.de/ethereum/2022/… but every time I have this discussion I get the same response from geth stakers that must be addressed: (0/9)

Here's an overview of everything that's been proposed (so far) for Prague/Electra 👀 See the full thread on @EthMagicians 🧙‍♀️ ethereum-magicians.org/t/prague-elect…

By popular demand, an updated roadmap diagram for 2023!

I've always admired @0xdoug's passion for DeFi and his thoughtful remarks about our industry. But I must say that his recent take is off the mark. Shorter block time is not simple. It inherently involves a tradeoff between network synchrony assumptions and protocol security [1,2]. Given the same synchrony assumption, you lose security when you have a shorter block time. If you decrease block time, you must also increase network synchrony requirements to maintain the same security. If not, various types of balancing attacks could occur on the base layer [3,4]. Moreover, important elements such as ePBS (in protocol builders), inclusion list (for censorship resistance), single slot finality (improving UIUX and security), and secret leader election (enhancing security) typically require extended block time for implementation. This is due to the need for an additional round of observation and communication. Lastly, desirable features, such as making Ethereum provably secure (Goldfish [5,6]), also need an extra round of communication. This goes into the next point which is why not just make Ethereum mainnet more application friendly? It is becoming more friendly, just look at the upcoming upgrade here: Now what about increasing the gas limit? I think it would be great for mainnet dApps and maybe also L2s, but once again making blocks bigger -> increases the network synchrony assumptions and also increases the mainnet state bloat problem - two problems that are at the heart of any distributed system design. Even from a practical standpoint: what good does it do to increase gas from 30 million to 300 million / block today? Does it make Ethereum more long-term competitive against other layers? I do not see how that's the case. 120 TPS is still too small. Lastly, the vision for Ethereum has always been rollup-centric. As @hasufl pointed out, the primary purpose of the base layer is to ensure security. Additionally, the base layer will offer the asset $ETH itself. Maybe there are some great arguments against this direction but I have not heard a nuanced case against it. On a personal note, for most of my conversations with EF and EF-adjacent folks, block time has always been a discussion topic, especially around MEV. I do not know where this refusal to discuss comes from. Ultimately, this might be how a functioning decentralized protocol works. We see the same situation from various perspectives and eventually strive to find mutual ground to continue forward❤️ Happy holidays🥰 Notes: 1: Everything is a Race and Nakamoto Always Wins arxiv.org/pdf/2005.10484… 2: Chapter 7: ee374.stanford.edu/blockchain-fou… 3:Two Attacks On Proof-of-Stake arxiv.org/pdf/2203.01315… 4: Three Attacks on Proof-of-Stake Ethereum arxiv.org/pdf/2110.10086… 5: Goldfish: No More Attacks on Proof-of-Stake Ethereum arxiv.org/pdf/2209.03255… 6: Goldfish: A Provably Secure Replacement for LMD GHOST in PoS Ethereum paradigm.xyz/2022/09/goldfi…

a small christmas present 🎁 for cryptotwitter – we are ecstatic to share "Execution Tickets," an idea from @drakefjustin on a reimagined blockspace market! dive into the design + implications here↓ 👽🎟️ ethresear.ch/t/execution-ti… thanks for reading, and see you next year🎄🪩🎉