Gratulerer med 10-årsdagen til Ethereum! Det er en underdrivelse å si at dette prosjektet har vært livsendrende ❤️

OG HER ER DEN: Første 45 millioner gassgrenseblokk foreslått på #Ethereum Mainnet! 🔥🚀 Neste mål: 60 millioner 📈

Gassgrensen beveger seg sakte oppover! Vi bør være på 45M snart. Hvis du kjører en validator, er alt du trenger å gjøre å oppdatere programvaren!

Headliner-valg fra alle kundeteam: Utførelse lag: - Geth: EIP-7928 (tilgangslister på blokknivå) - Reth: EIP-7928 + EIP-7732 (ePBS) + EIP-7805 (FOCIL) strekning - Erigon (både EL + CL): EIP-7928 + EIP-7805 + EIP-7782 (reduser blokkforsinkelse) - Nethermind: EIP-7928 + EIP-7732 og støtter også EIP-7805 + EIP-7692 - Besu: EIP-7928 + EIP-7732 + EIP-7805 strekk Konsensus lag: - Fyrtårn: EIP-7732 (ePBS) - Prysm: EIP-7732 + EIP-7805 strekk - Grandine: EIP-7732 + EIP-7805 strekk - Lodestar: EIP-7732 + EIP-7805 stretch + EIP-7919 Pureth for EL - Teku: EIP-7732 - Nimbus (begge CL + EL): EIP-7732 + EIP-7919

er det noen som kjenner til tidligere forsøk på å bygge en matematisk båndbreddeutnyttelsesmodell for Eth? når vi skalerer L1-kapasitet + gjennomstrømning, skalerer blobber, omstrukturerer sporet, øker forplantningseffektiviteten, legger til nye mekanismer (f.eks. FOCIL, BAL), fragmenterer mempoolen osv., jobber vi mot begrensningene til EIP-7870. Vi vil dra nytte av en modell der vi kan slå inn parametere som blokkgassgrense, mempool-trykk, blob-antall, forplantningskostnader og effektivitetsfaktorer, blob-antall, blob-utnyttelse, validatorantall, aktivt antall jevnaldrende, sjekkpunktsynkroniseringsaktivitet, etc. for å visualisere hvordan det hele stabler seg opp langs sporets tidslinje. også for å varsle oss når valgene våre bryter med EIP-7870. På designtidspunktet vil dette hjelpe oss med å resonnere om avveininger, båndbreddeallokering, gjennomstrømning/goodput. Det bidrar også til å drive diskusjon om aktiv trafikkforming, der vi eksplisitt prioriterer visse typer aktivitet på forskjellige tidspunkter (og gassbåndbredde til andre) for å maksimere den totale systemeffektiviteten. i hovedsak en justerbar matematisk modell av selve elementdiagrammet nedenfor (som utelater mye),

Tok en titt på hele Ethereum-validatorsettet for å beregne hvor mange konsolideringsmuligheter som gikk glipp av etter Pectra-oppgraderingen. Nøkkelstatistikk: - Siden pectra har 96 672 nye validatorer blitt aktivert - 79 547 av disse validatorene kunne ha blitt konsolidert, de gjenbrukte en pre-pectra-uttakslegitimasjon - 14 362 av disse validatorene gjenbrukte en post-pectra-uttakslegitimasjon - Dette gjenstår bare 2,763 virkelig "unike" validatorer! På et tidspunkt må vi spørre hva som hindrer validatorer i å konsolidere, er det verktøy for modenhet, tidsramme for tillit eller noe annet? Glad for å hjelpe noen med å konsolidere eller snakke gjennom det, bare send meg en DM

Nei seriøst, hva ER egentlig en @ethereum fork "headliner"? Hvem gagner de foreslåtte EIP-ene? Hvordan sammenligner vi oss på tvers av dem? Teamet mitt på @ethereumfndn ønsker å gjøre oppgraderingsprosessen lettere å forstå. Jeg er glad for å dele et smol-verktøy vi har hacket på: 🧵 ↓

Etter en veldig produktiv personlig uke med kundeutviklere, kom vi frem til en plan for hvordan vi ønsker å takle skalering og utfordringene som kan oppstå. Forvent en jevn strøm av analyser og progressive oppdateringer av gassgrensen i fremtiden.

Attestasjons forplantning: I tapte plasser (ingen blokkering) utsetter attestanter til attestasjonsfristen. Dette gir oss rene data om når ikke-aggregerte attester treffer noder. Selv raske, godt tilkoblede Xatu-noder (DC-hosted) ser bare ~40 % av attestasjonene etter 1 s; langsommere treffer 40 % etter 2 s. Dette er ventetidsobservasjoner som er bedre enn gjennomsnittet.

Spesiell interoperativ utgave av Checkpoint-serien! Checkpoint-innleggene er tilgjengelige oppdateringer for @ethereum kjerneutvikling. Den siste uken møttes kjerneutviklere og forskere for en personlig hackinguke i løpet av @BerBlockWeek, og dette er et innblikk i hva de gjorde: