Mange ba om en enkel veiledning om simulering av transaksjoner. Jeg har nettopp lagt til nye funksjoner i verktøyet: det kan nå fungere som en RPC, avskjære og simulere transaksjoner før de forplantes. Slik sender du en transaksjon på under 1 minutt på en sikker måte:

Blind signering er risikabelt. Jeg har brukt et enkelt skript i årevis for å trygt forhåndsvise transaksjoner før jeg sender dem. Med litt AI-assistanse gjorde jeg det om til et CLI-verktøy slik at du enkelt kan simulere transaksjonen din før kringkasting. 👉

EIP-7928 (Block-Level Access Lists) har som mål å bringe parallell transaksjonsbehandling til Ethereum. Denne EIP-en vurderes for tiden for inkludering i Ethereums Glamsterdam-oppgradering (rettet mot midten av 2026) Dette vil muliggjøre større total effektivitet for Ethereum-nettverket.

Block-Level Access Lists (EIP-7928) er en favoritt for Glamsterdam og rangerer høyt blant både fellesskapet og kjerneutviklerne. kuraterer klientfremgang, analyser, kode, EL/Engine API-spesifikasjoner og -tester, pluss mainnet JSON-eksempler, alt for å komme i gang.

Ble overrasket over å høre at ePBS (EIP 7732) anses som sannsynlig å være planlagt til Glamsterdam på morgendagens ACD-samtale, og spesielt at det blir sett på som en erstatning for forsinket utførelse (som EIP 7886) Har aldri hørt en veldig god grunn til å gjøre forsinket utførelse på konsensuslaget i stedet for utførelseslaget. I motsetning til EIP 7886, hjelper ikke ePBS med å forenkle byggere – de må fortsatt utføre hele blokken for å generere tilstandsroten Som mange har påpekt, virker valgfrihetsproblemet ille (8 sekunder for en byggherre å kansellere blokken sin!). Selv når alternativet ikke utøves, kan dette legge til mye ventetid før brukere kan se om transaksjonen deres ble inkludert Men det virker også bare som nok en kompleks endring som ikke gjør noe for å hjelpe brukerne, som jeg trodde Ethereum beveget seg forbi

Gassrefusjoner for å rydde lagringsspor hjelper mot statlig oppblåsthet, men forvrenger også blokkgassregnskapet, noe som gjør at blokker ser mindre ressurskrevende ut enn de egentlig er. Her er hvorfor det er et problem, og hvordan EIP-7778 løser det: TLDR i denne tråden👇

Ethereum skalerer. Neste stopp - > 45M.

Her får jeg igjen alle til å huske at @ethereum har kunder og at vi må betjene dem. Jeg mener EIP-7928 bør være en av de største prioriteringene for @ethereum. Det vil muliggjøre parallelle disklesinger, validering av parallelle transaksjoner og utførelsesfrie tilstandsoppdateringer. Den andre tingen jeg mener Ethereum bør prøve å gjøre er EIP-7782 for å redusere Ethereums spilleautomattid fra 12s til 6s for å redusere ventetiden med 50%, distribuere båndbreddebruk og forbedre UX. EIP-7732 Enshrined Proposer-Builder Separation som mange av ingeniørene ønsker å jobbe først er interessant, men jeg tror ikke det tilfører for mye for sluttbrukeren og det legger til mye kompleksitet. Vi kan legge til flere begrensninger i systemet. Jeg tror vi må skalere det først. Jeg tror vi først må fokusere på veldig konkrete ytelses- og UI/UX-relaterte funksjoner. Jeg har fulgt arbeidet @NethermindEth og @paradigm har presset på for å øke gassgrensen, og jeg mener denne typen initiativer bør prioriteres. Fortsett det gode arbeidet.

CDF av Ethereum-blokkforplantningsforsinkelser på tvers av land, målt i forhold til den raskeste noden per spor (blokk først sett). Bare noen få land (FI, CH) oppnår forsinkelser under 100 ms; de fleste viser 200–500 ms median forsinkelse. Dette representerer et nedre grenseestimat for blokkutbredelse.

1/ Bør Ethereum sende ePBS (EIP-7732) i Glamsterdam, eller er et slankere alternativ bedre? La oss pakke ut. Hele innlegget 👇