Grattis på 10-årsdagen till Ethereum! Det är en underdrift att säga att detta projekt har förändrat livet ❤️

OCH HÄR ÄR DEN: Det första blocket med 45 Milions gasgräns föreslås på #Ethereum Mainnet! 🔥🚀 Nästa mål: 60M 📈

Gasgränsen rör sig långsamt uppåt! Vi borde vara på 45M snart. Om du kör en validerare är allt du behöver göra att uppdatera din programvara!

Headliner-val från alla kundteam: Utförande Lager: - Geth: EIP-7928 (Åtkomstlistor på blocknivå) - Längd: EIP-7928 + EIP-7732 (ePBS) + EIP-7805 (FOCIL) sträckning - Erigon (både EL + CL): EIP-7928 + EIP-7805 + EIP-7782 (minska blocklatens) - Nethermind: EIP-7928 + EIP-7732 och stöder även EIP-7805 + EIP-7692 - Anslutning: EIP-7928 + EIP-7732 + EIP-7805 stretch Konsensus lager: - Fyr: EIP-7732 (ePBS) - Prysm: EIP-7732 + EIP-7805 stretch - Längd: EIP-7732 + EIP-7805 stretch - Lodestar: EIP-7732 + EIP-7805 stretch + EIP-7919 Pureth för EL - Källa: EIP-7732 - Nimbus (både CL + EL): EIP-7732 + EIP-7919

är det någon som känner till tidigare ansträngningar för att bygga en matematisk modell för bandbreddsutnyttjande för Eth? när vi skalar L1-kapacitet+genomströmning, skalar blobbar, omstrukturerar facket, ökar utbredningseffektiviteten, lägger till nya mekanismer (t.ex. FOCIL, BAL), skärva mempoolen, etc. arbetar vi mot begränsningarna i EIP-7870. Vi skulle dra nytta av en modell där vi kan slå in parametrar som blockgasgräns, mempooltryck, blobantal, spridningsoverhead och effektivitetsfaktorer, blobantal, blobanvändning, validatorantal, aktivt peer-antal, checkpoint-synkroniseringsaktivitet etc. för att visualisera hur allt står sig längs slottets tidslinje. också för att varna oss när våra val bryter mot EIP-7870. Vid designtillfället skulle detta hjälpa oss att resonera om kompromisser, bandbreddsallokering, dataflöde/goodput. Det bidrar också till att driva diskussioner om aktiv trafikformning, där vi uttryckligen prioriterar vissa typer av aktivitet vid olika tillfällen (och stryper bandbredden till andra) för att maximera den totala systemeffektiviteten. i huvudsak en justerbar matematisk modell av det mycket elementära diagrammet nedan (som utelämnar mycket),

Tog en titt på hela Ethereum-valideraren för att beräkna hur många konsolideringsmöjligheter som missades efter Pectra-uppgraderingen. Viktig statistik: - Sedan pectra har 96 672 nya validerare aktiverats - 79 547 av dessa validerare kunde ha konsoliderats, de återanvände en pre-pectra-uttagslegitimation - 14 362 av dessa validerare återanvände en inloggningsuppgift efter PECTRA-uttag. - Detta lämnar bara 2 763 verkligt "unika" validerare! Vid någon tidpunkt måste vi fråga oss vad som hindrar validerare från att konsolidera, är det verktygsmognad, konfidenstidsram eller något annat? Glad att hjälpa någon att konsolidera eller prata igenom det, bara DM mig

Nej seriöst, vad ÄR ens en @ethereum gaffel "headliner"? Vem gynnas av de föreslagna europeiska innovationspartnerskapen? Hur står vi oss i jämförelse mellan dem? Mitt team på @ethereumfndn vill göra uppgraderingsprocessen lättare att förstå. Jag är taggad på att dela med mig av ett smol-verktyg som vi har hackat på: 🧵 ↓

Efter en riktigt produktiv vecka med kundutvecklare kom vi fram till en plan för hur vi vill hantera skalning och de utmaningar som kan uppstå. Förvänta dig en stadig ström av analyser och progressiva uppdateringar av gasgränsen i framtiden.

Spridning av intyg: I missade platser (inget block) fördröjer attesterna tills tidsgränsen för attestering har löpt ut. Detta ger oss rena data om när icke-aggregerade attesteringar träffar noder. Även snabba, väl anslutna Xatu-noder (DC-värdar) ser bara ~40 % av attesteringarna efter 1 s; Långsammare når 40% efter 2s. Det här är svarstidsobservationer som är bättre än genomsnittet.

Speciell interop-utgåva av Checkpoint-serien! Checkpoint-inläggen är tillgängliga uppdateringar av @ethereum kärnutveckling. Den senaste veckan träffades kärnutvecklare och forskare för en personlig hackingvecka under @BerBlockWeek och det här är en inblick i vad de gjorde: