den , schemalagd för aktivering på , är Ethereums nästa stora nätverksuppgradering efter Pectra, och det markerar ett ytterligare skalande steg som gjorts av kryptogiganten. Fusaka hard fork December 3, 2025 Fusaka hard fork Pectra EIPs fokuserar på att förbättra prestanda, säkerhet och utvecklingsverktyg. ) gör data tillgänglighet mer effektivt genom att låta noder verifiera blobs utan att ladda ner allt. Flera uppgraderingar skärper utförande säkerhet, inklusive gränser på ModExp ( ), en gräns för transaktion gas gränser ( ), och uppdaterade ModExp gaskostnader ( Förbättring av tillverkningsprocessen med hjälp av deterministiska propositor lookahead ( ) och håller blobavgifterna stabila med gränser kopplade till genomförandekostnader ( ) Ytterligare förbättringar inkluderar begränsning av blockstorlek i RLP-format ( ), lägga till en ny CLZ opcode för snabbare bitoperationer ( ), och införandet av en secp256r1 precompile ( För bättre kompatibilitet med moderna kryptografiska och hårdvarusäkerhetsnycklar. EIP-7594 EIP-7823 EIP-7825 EIP-7883 EIP-7917 EIP-7918 EIP-7934 EIP-7939 EIP-7951 Precis som Pectra kombinerade "Prague" och "Electra", är Fusaka ett kombinerat namn för och Det representerar Ethereums nästa steg mot en mycket skalbar, data-rik framtid där Layer 2 rollups kan fungera billigare och snabbare. Fulu (execution layer) Osaka (consensus layer) I den här bloggen kommer vi att bryta ner kärnfunktionerna i Fusaka hard fork, förklara hur PeerDAS fungerar i praktiken och gå igenom de verkliga nätverkskraven för hemstackare, supernoder och fulla noder - backad av devnet-data. Key Changes Introduced In Fusaka Hard Fork Viktiga förändringar introducerade i Fusaka Hard Fork : PeerDAS - Peer Data Availability Sampling EIP-7594 Öppna 7594 Ethereum behövde detta förslag eftersom nätverket vill ge mer data tillgänglighet för användare och särskilt för rollups, men med den nuvarande Design, varje nod måste fortfarande ladda ner för mycket blob data bara för att kontrollera att det faktiskt publicerades. Detta skapar ett skalningsproblem eftersom om alla noder måste ladda ner allt, nätverkets bandbredd och hårdvarukrav går upp, och decentralisering kan lida. För att fixa detta behöver Ethereum ett sätt för noder att bekräfta att data är tillgänglig utan att ladda ner allt. Data Availability Sampling (DAS) löser detta genom att låta noder bara kolla små slumpmässiga bitar av data. Men Ethereum behöver också en DAS-metod som passar bra med det befintliga gossip-nätverket och lägger inte till tung beräkning till blockproducenter. PeerDAS skapades för att möta dessa behov och säkert öka blobput genom att hålla nodkrav låga. EIP-4844 PeerDAS är ett nätverkssystem som tillåter noder att ladda ner endast små bitar av blob data för att kontrollera att hela data faktiskt publicerades. I stället för att ladda ner allt, noder använder det normala gossip nätverk för att dela data, upptäcka vilka peers har vissa delar, och begära bara de små prover de behöver. Den huvudsakliga idén är att genom att ladda ner bara små, slumpmässiga delar av blob, noder kan fortfarande vara säker på att hela blob existerar. Till exempel, istället för att ladda ner en full 256 KB blob, en nod kan ladda ner bara ungefär 1/8 av det - men eftersom många noder prov olika delar, eventuella saknade data skulle snabbt märkas. För att göra provtagning arbete, PeerDAS expanderar varje blob från använda en grundläggande typ av borttagningskodning. — På samma sätt som du kan slutföra ett pussel även om några bitar är förlorade. Blob blir en "rad" som innehåller de ursprungliga data plus några extra kodade data som gör det möjligt att bygga om senare. Den här raden är sedan uppdelad i många små bitar som kallas celler, som är de minsta verifierade enheterna kopplade till ett KZG-engagemang. Alla rader omorganiseras sedan till "kolumner", där varje kolumn innehåller cellen i samma position från varje rad. Varje kolumn tilldelas ett specifikt gossip-undernät. Noder är ansvariga för att lagra vissa kolumner baserat på deras nod-ID och för att samla några kolumner från varje peer-slot. Om en nod samlar in minst 50% av alla kolumner, kan den helt återuppbygga EIP-4844 Erasure coding is a technique that adds extra redundant data so that the original data can be recovered even if some pieces are missing Dessutom inför EIP en viktig regel: . This limit must be enforced during transaction validation, gossip, block creation, and block processing. This helps reduce extreme cases where a single transaction overloads the blob system. no transaction can contain more than 6 blobs PeerDAS lägger till något som heter Ett cell KZG-bevis visar att ett KZG-åtagande verkligen matchar en specifik cell (ett litet stycke) i en blob. Detta gör det möjligt för en nod att hämta endast de celler som den vill prova, i stället för den fullständiga blob, samtidigt som dataintegriteten garanteras. cell KZG proofs Men att generera alla dessa cellbevis är dyrt. En blockproducent skulle behöva beräkna dem om och om igen för många blobs, vilket är för långsamt. att generera alla cellbevis i förväg och inkludera dem i transaktionsförpackningen. the blob transaction sender På grund av detta, transaktion gossip (PooledTransactions) använder nu en modifierad wrapper: rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) Inuti den nya tråden, är bara en lista som innehåller varje bevis för varje cell i varje blob (till exempel: ). The other fields — och och - är exakt samma som de var i EIP-4844.Skillnaden är att det gamla enkla "bevis" fältet tas bort och ersätts med detta nya listan, och ett nytt fält som kallas läggs till för att visa vilket wrapper-format som används. cell_proofs [cell_proof_0, cell_proof_1, ...] tx_payload_body blobs commitments cell_proofs wrapper_version den är en enda byte, och i detta förslag är det alltid och den fältet innehåller alla cellbevis för varje blob, inklusive bevis för de extra förlängningsceller som skapats under raderingskodning. Även om listan innehåller bevis för förlängningscellerna skickas bloberna fortfarande i sin normala (icke-utökade) form. En blob innehåller endast sin ursprungliga hälft – den mottagande noden kan beräkna förlängningshalvan på egen hand, så det finns inget behov av att skicka onödiga data. wrapper_version 1 cell_proofs CELLS_PER_EXT_BLOB och mer formellt, är beviset för j-cellen i i-blob efter körning , som producerar både original- och förlängningsceller. cell_proofs[i * CELLS_PER_EXT_BLOB + j] compute_cells(blobs[i]) När en nod får denna omslag, måste den validera transaktionen och kontrollera att allt linjer upp korrekt. Det måste kontrollera att antalet versionerade hashes, blobs och åtaganden alla matchar. Det måste också bekräfta att Innehåller exakt Varje enskild artikel måste ha en matchande version av hash ( Slutligen måste noden kontrollera att varje åtagande faktiskt matchar blob och dess bevis. , and then verifies all the cell proofs—batch verification is allowed to make this faster. cell_proofs CELLS_PER_EXT_BLOB * number_of_blobs kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] compute_cells Föreställ dig att en blob är uppdelad i efter borttagning av kodning ( Den ursprungliga blob innehåller , och den mottagande noden kommer att beräkna den saknade sändare, men sändaren måste innehålla i . Example 8 cells CELLS_PER_EXT_BLOB = 8 4 cells 4 extension cells all 8 proofs cell_proofs Så för 1 blob innehåller transaktionswrapper: blobs = [blob_0] (endast original 4 celler) Förpliktelser = [förpliktelse_0] cell_proofs = [proof_0, proof_1, ..., proof_7] (bevis för var och en av de 8 cellerna) När en nod samlar, kan den begära endast cell 2 eller cell 5, och det kan verifiera dem omedelbart med hjälp av matchande bevis, utan att någonsin ladda ner hela blob. PeerDAS tillåter Ethereum att öka data tillgänglighet utan att göra noder arbeta hårdare. I framtiden kan detta till och med gå ner till , vilket skulle låta Ethereum skala mer. Systemet fungerar bra eftersom varje nod har många peers. Så om en peer inte ger de nödvändiga data, kan noden helt enkelt be en annan peer. Detta skapar naturlig redundans och förbättrar säkerheten. noder kan också välja att lagra data än nödvändigt, vilket ytterligare stärker nätverket – även utan några protokolländringar. 1/8 of the total blob data 1/16 or 1/32 more Validerare har lite mer ansvar än normala fullständiga noder. Eftersom validerare redan kör starkare hårdvara ger PeerDAS dem en data-custody-last som matchar det totala antalet validerare. Detta säkerställer att en stabil grupp noder alltid är tillgänglig för att lagra och dela mer data, vilket gör nätverket mer tillförlitligt. Kort sagt, om det finns 900 000 validerare, kan varje validerare tilldelas en liten del av den totala blob-data för att lagra och betjäna. Eftersom validerare har bättre maskiner, kan nätverket lita på dem för att hålla dessa data tillgängliga. PeerDas använder Istället för radprovtagning eftersom det gör ombyggnationen av data mycket lättare. Om noder provade hela rader (hela blobs), skulle de behöva skapa ytterligare "förlängningsblobs" som inte existerar naturligt, vilket skulle sakta ner blockproducenterna. Genom att samla kolumner kan noderna förbereda extra raddata i förväg, och transaktionssändarna - inte blockproducenterna - beräkna de nödvändiga bevisen. Föreställ dig att en blob är ett 4×4-nät av celler. Row sampling skulle innebära att ta alla 4 celler från en rad, men vissa förlängningsrader är inte redo ännu, så blockproducenten skulle behöva generera dem på plats. Kolumn sampling innebär att ta en cell från varje rad (en kolumn). De extra celler som behövs för rekonstruktion kan förberedas i förväg, så noder kan verifiera data utan att sakta ner blockproduktionen. column sampling Example: Fungerar fullt ut med , så det bryter inte någonting redan på Ethereum. Alla tester och detaljerade regler är i konsensus och utförande specifikationer. EIP-7594 EIP-4844 PeerDAS förhindrar detta genom att använda slumpmässig sampling: noder kontrollerar slumpmässiga delar av data. Ju fler noder som samplas, desto svårare är det för en angripare att fuska. EIP ger även en formel för att beräkna hur sannolikt ett sådant angrepp kan lyckas, baserat på det totala antalet noder (n), totala prover (m) och prover per nod (k). På Ethereum mainnet, med cirka 10 000 noder, är chansen för en framgångsrik attack extremt liten, så PeerDAS anses vara säker. The table shows that the chances of a successful attack drop to a negligible level, which is why PeerDAS is considered secure against data-withholding attacks. For deeper analysis, you can refer to the linked . blog : Set upper bounds for MODEXP EIP-7823 Öppna 7823 Detta förslag är nödvändigt eftersom den nuvarande MODEXP precompile i Ethereum har orsakat många konsensus buggar under åren. De flesta av dessa buggar hände eftersom MODEXP tillåter extremt stora och orealistiska inmatningsstorlekar, vilket skapar oändliga, ovanliga fall som kunder måste hantera. Eftersom varje nod måste bearbeta vad inmatning en transaktion ger, utan övre gräns gör MODEXP svårare att testa, lättare att bryta och mer benägna att bete sig annorlunda över olika kunder. Mycket stora inmatningar gör också gaskostnadsformeln svår att förutsäga, eftersom det är svårt att prissätta något när dess storlek kan växa utan gräns. Dessa problem gör det också svårt att ersätta MODEXP med framtida EVM-nivå kodverktyg som EVM EIP-7823 introducerar en enkel regel: alla tre längdfält som används av MODEXP – storleken på BASE, EXPONENT och MODULUS – måste vara , vilket är 1024 bytes. MODEXP-ingångar följer formatet Som definierat i , så denna EIP begränsar endast längdvärdena. Om någon längd överstiger 1024 bytes, stannar förkompilationen omedelbart, returnerar ett fel och bränner all gas. Till exempel, om någon försöker tillhandahålla en BASE som är 2000 bytes lång, kommer samtalet att misslyckas innan något arbete händer. Dessa gränser stöder fortfarande alla faktiska användningsfall. RSA-verifiering använder vanligtvis nyckelstorlekar som 1024, 2048 eller 4096 bitar, allt inom den nya gränsen. Elliptiska kurvor använder ännu mindre storlekar, ofta under 384 bitar, så de påverkas inte heller. 8192 bits or less <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> EIP-198 Dessa nya gränser hjälper också till med framtida uppgraderingar. Om MODEXP någonsin skrivs om i EVM-kod med EVMMAX, kan utvecklare lägga till optimerade vägar för vanliga inputstorlekar som 256 bitar, 381 bitar eller 2048 bitar och använda en långsammare fallback för sällsynta fall. Med fasta maxstorlekar kan utvecklare till och med lägga till speciell hantering för mycket vanliga modulvärden. Inget av detta var realistiskt tidigare, eftersom de obegränsade inputstorlekarna gjorde designutrymmet för stort för att hantera säkert. För att bekräfta att denna förändring inte skulle bryta tidigare transaktioner analyserade författarna all MODEXP-användning från block 5,472,266 (20 april 2018) till block 21,550,926 (4 januari 2025). , långt under den nya 1024-bytegränsen.De flesta riktiga samtal använde små längder som 32 bytes, 128 bytes eller 256 bytes.Det fanns några ogiltiga eller trasiga samtal, såsom tomma ingångar, ingångar fyllda med upprepande bytes som Dessa skulle bete sig likadant under de nya gränserna eftersom de redan var ogiltiga.Så, medan EIP är tekniskt en brytande förändring, i praktiken skulle det inte ha förändrat resultatet av någon tidigare transaktion. 513 bytes 0x9e5faafc Från ett säkerhetsperspektiv minskar minskningen av de tillåtna ingångsstorlekarna inte nya risker. Istället tar det bort onödiga extrema fall som tidigare orsakade buggar och inkonsekvenser över klienter. Genom att begränsa MODEXP-ingångar till realistiska storlekar gör detta EIP systemet mer förutsägbart, minskar konstiga hörnfall och minskar risken för fel mellan olika implementationer. Dessa begränsningar hjälper också till att förbereda systemet för en smidigare övergång om framtida uppgraderingar som EVMMAX introducerar optimerade utförandevägar. : Transaction Gas Limit Cap EIP-7825 Övrigt EIP-7825 Ethereum behövde detta förslag eftersom idag en enda transaktion kan använda nästan hela blockgasgränsen. Detta skapar flera problem: en transaktion kan förbruka de flesta av blockens resurser och orsaka en DoS-stilavmattning, stora gasviktiga operationer kan öka Ethereums tillstånd för snabbt, och blockvalidering blir långsammare och svårare för noder att hålla jämna steg med. Om en användare skickar in en stor transaktion som använder nästan all gas (till exempel en transaktion som förbrukar 38 miljoner gas i ett 40 miljoner–gasblock), då andra normala transaktioner inte kan passa in i blocket, och varje nod måste spendera extra tid på att verifiera det blocket. Detta hotar nätverksstabilitet och decentralisering eftersom långsammare verifiering innebär svagare noder som faller bakom. EIP-7825 introducerar en hård regel att ingen transaktion kan använda mer än Detta blir en protokollnivåkapacitet, vilket innebär att den gäller överallt: när en användare skickar en transaktion, när txpoolen kontrollerar den och när validerare inkluderar den i ett block. Denna gräns är helt oberoende av blockgasgränsen.Till exempel, även om blockgasgränsen är 40 miljoner, är ingen enskild transaktion tillåten att använda över 16,7 miljoner gas. 16,777,216 gas (2²⁴) MAX_GAS_LIMIT_EXCEDED Överskrid MAX_GAS_LIMIT_EXCEDED Överskrid För att förstå detta bättre, föreställ dig att ett block har utrymme för 40 miljoner gaser. Utan denna cap kan någon skicka en enda transaktion som förbrukar 35-40 miljoner gaser. Den transaktionen skulle monopolisera blocket och lämna inget utrymme för andra, liknande en person hyr ut en hel buss så att ingen annan kan gå ombord. Med den nya 16,7M-gränsen kommer blocket naturligtvis att hålla flera transaktioner och undvika denna typ av missbruk. Förslaget lägger också till specifika krav på hur klienterna validerar transaktioner. txpool måste avvisa en transaktion om dess gasLimit är över 16,777,216, vilket innebär att en sådan transaktion aldrig ens går i kö. Under blockvalidering, om ett block innehåller en transaktion som överskrider gränsen, måste själva blocket avvisas. Internalt kommer klientimplementationer att begränsa GAS_LIMIT-parametern för alla transaktioner vid detta värde. Numret är valdes eftersom det är en ren makt-av-två gräns, vilket gör det lättare att implementera, och det är fortfarande tillräckligt stort för att hantera de flesta verkliga transaktioner som smarta kontrakt utbyggnad, komplexa DeFi interaktioner, eller flerstegs kontrakt samtal. 16,777,216 (2²⁴) Denna EIP upprätthåller också kompatibilitet med den nuvarande gasmekaniken. De flesta användare kommer aldrig att märka förändringen eftersom nästan alla befintliga transaktioner redan förbrukar mycket mindre än 16 miljoner gas. Validerare och blockbyggare kan fortfarande skapa block som överstiger 16,7 miljoner totala gas, så länge varje enskild transaktion respekterar den nya gränsen. De enda transaktioner som påverkas är extremt stora som tidigare försökt använda mer än den nya gränsen. Dessa transaktioner måste nu delas upp i flera mindre operationer – liknande att bryta en mycket stor fil uppladdning i två mindre. Denna förändring är tekniskt inte bakåtkompatibel för dessa sällsynta extrema transaktioner, men antalet användare som påverkas förväntas vara mycket liten. När det gäller säkerhet gör gaskappen Ethereum mer motståndskraftigt mot gasbaserade DoS-attacker eftersom angripare inte kan tvinga validerare att hantera extremt stora transaktioner längre. Det hjälper också till att hålla blockverifieringstider förutsägbara så att noder kan förbli synkroniserade lättare. Sammantaget är EIP-7825 utformad för att stärka nätverket mot missbruk, hålla nodkrav rimliga, förbättra rättvisan i blockutrymmesanvändning och säkerställa att kedjan förblir snabb och stabil som gasgränser fortsätter att öka över tiden. : ModExp Gas Cost Increase EIP-7883 Öppna 7883 Anledningen till att Ethereum behöver detta förslag är att ModExp precompile (används för modulär exponentiering) har I vissa situationer kräver ModExp-operationer mycket mer beräkning än vad användarna för närvarande betalar för. Denna missmatchning skapar en risk: om komplexa ModExp-samtal förblir för billiga, kan de bli en och göra det svårare för nätverket att säkert öka blockgasgränsen, eftersom blockproducenter kan bli tvungna att bearbeta extremt tunga operationer för mycket låg kostnad. För att fixa detta måste Ethereum justera ModExp prissättning formel så att den gas som används korrekt återspeglar det verkliga arbetet som gjorts av kunden. Det är därför EIP-7883 introducerar nya regler som ökar minimikostnaden, höjer den allmänna kostnaden och gör operationer med stora ingångar (särskilt exponenter, bas eller modul över 32 byte) dyrare, så att gasprissättning matchar den verkliga beräkningen som krävs. underpriced bottleneck Detta förslag ändrar ModExp prissättning algoritm som ursprungligen definierades i EIP-2565 genom att öka kostnaden på flera viktiga sätt. is raised from 200 to 500, and the general formula no longer divides by 3, meaning the total cost effectively becomes . For example, if a ModExp call previously cost 1,200 gas, it will now cost around 3,600 gas under the new formula. Second, the cost of operations with fördubblas genom att öka multiplikatorn från 8 till 16. För att illustrera detta: om exponentlängden var 40 bytes, skulle EIP-2565 antalet iterationer, medan EIP-7883 nu använder , vilket gör det dubbelt så dyrt. Tredje, priset antar nu en Det är viktigt att ha koll på vad som händer om det är en stor del av den totala kostnaden för att utföra beräkningen, till exempel om modulen är 64 byte, tillämpar den nya regeln en dubbel komplexitet ( Tillsammans säkerställer dessa förändringar att små ModExp-operationer betalar en rättvis minimikostnad och stora, tunga operationer skalar sina kostnader ordentligt med storlek. minimum gas cost three times higher exponents larger than 32 bytes 8 × (40 − 32) = 64 16 × (40 − 32) = 128 minimum base/modulus size of 32 bytes 2 × words² Förslaget definierar en ny gasberäkningsfunktion som uppdaterar komplexitets- och iterationsberäkningsreglerna. Multiplikationskomplexiteten använder nu ett standardvärde på 16 för bas/modullängder upp till 32 byte, och för större inmatningar växlar den till den tyngre formeln , där "ord" är antalet 8-byte bitar. Iterationsräkningen uppdateras också så att exponenter med 32 byte eller mindre använder sin bitlängd för att bestämma komplexiteten, men exponenter större än 32 byte lägger till en mycket större straff. Detta säkerställer att mycket stora exponenter, som är beräkningskostsamma i praktiken, nu har en mycket högre gaskostnad. 2 × words² Motivationen bakom dessa prishöjningar kommer från riktmärken som visar många situationer där ModExp precompile var betydligt underprissatt. Typiska operationer runt omkring , och mycket stora eller obalanserade operationer av mycket större faktorer - ibland mer än —beroende på hur stor exponenten, basen eller modulen är. Avsikten är inte att ändra hur ModExp fungerar, utan att se till att även i sina mest resursintensiva kantfall hotar det inte längre nätverksstabiliteten eller förhindrar framtida ökningar till blockgasgränsen. , but gas repricing has happened many times before in Ethereum and is well-understood. 150% 200% 80× backward-incompatible Testresultaten visar hur signifikant ökningen kan vara. kommer nu att kosta antingen 500 gas (upp från 200) eller tre gånger sitt tidigare pris. Men vissa tunga testfall ser enorma ökningar. —eftersom extremt stora exponenter nu prissätts korrekt.I ett annat fall som involverar en basviktig operation går kostnaden från 1,026 till 94,448 gas, vilket återspeglar hur storsiffrig multiplikation faktiskt skalar.Dessa exempel visar varför den gamla prissättningsformeln inte var realistisk och hur den nya bättre matchar beräkningsrealiteten. 99.69% of historical ModExp calls 76× more In terms of security, this proposal does not create new attack vectors or make any operation cheaper. Instead, it focuses on preventing an important risk: underpriced ModExp operations could make it possible for attackers to fill blocks with extremely heavy computations for very low cost. The only possible downside is that some ModExp operations might now become overpriced, but this is considered a far better outcome than the current underpricing problem. No interface changes or new functionality are introduced, so existing arithmetic behavior and test vectors remain valid. Test Case EIP-2565 Pricing EIP-7883 Pricing Increase modexp_nagydani_1_square 200 500 150% modexp_nagydani_1_qube 200 500 150% modexp_nagydani_1_pow0x10001 341 2048 501% modexp_nagydani_2_square 200 512 156% modexp_nagydani_2_qube 200 512 156% modexp_nagydani_2_pow0x10001 1365 8192 501% modexp_nagydani_3_square 341 2048 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_nagydani_4_square 1365 8192 501% modexp_nagydani_4_qube 1365 8192 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 500% modexp_nagydani_5_qube 5461 32768 500% modexp_nagydani_5_pow0x10001 87381 524288 500% modexp_marius_1_even 2057 45296 2102% modexp_guido_1_even 2298 51136 2125% modexp_guido_2_even 2300 51152 2124% modexp_guido_3_even 5400 32400 500% modexp_guido_4_even 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500% modexp_marcin_2_base_heavy 867 5202 500% modexp_marcin_2_exp_heavy 852 16368 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_heavy 677 2032 200% modexp_marcin_3_exp_heavy 765 4080 433% modexp_marcin_3_balanced 1360 4080 200% modexp_gammal_1_kvadrat 200 500 150 procent modexp_gammal_1_kvb 200 500 150 procent modexp_gammal_1_gammal0x10001 341 2048 501 procent modexp_gammal_2_kvadrat 200 512 156 procent modexp_gammal_2_gammal 200 512 156% modexp_nagydani_2_pow0x10001 1365 8192 501 procent modexp_gammal_3_kvadrat 341 2048 501% modexp_gammal_3_gammal 341 2048 501 procent modexp_gammal_3_gammal0x10001 5461 32768 500 procent modexp_nagydani_4_square 1365 8192 501 procent modexp_nagydani_4_qube 1365 8192 501 procent modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 500% modexp_nagydani_5_qube 5461 32768 500 procent modexp_gammal_5_gammal0x10001 87381 524288 500 procent modexp_marius_1_even 2057 45296 2102% modexp_guido_1_even 2298 51136 2125 procent modexp_guido_2_även 2300 51152 2124 procent modexp_guido_3_även 5400 32400 500 procent modexp_guido_4_även 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500 procent modexp_marcin_2_base_hög 867 5202 500 procent modexp_marcin_2_exp_hög 852 16368 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_hög 677 2032 200% modexp_marcin_3_exp_hög 765 4080 433 procent modexp_marcin_3_balanced 1360 4080 200% *source: https://eips.ethereum.org/EIPS/eip-7883#test-cases* : Determine proposer lookahead EIP-7917 EIP 7917 Ethereum needed this proposal because the network’s proposer schedule for the next epoch was not fully predictable. Even though the RANDAO seed for epoch is known during epoch , den faktiska förslagsförteckningen kan fortfarande ändras på grund av effektiva balans (EB) uppdateringar som sker inom epoken . These EB changes can come from slashings, penalties, rewards above 1 ETH, validator consolidations, or new deposits—especially after EIP-7251 raised the maximum effective balance beyond 32 ETH. This uncertainty creates issues for systems that rely on knowing the next proposer in advance, such as based preconfirmation protocols, which need a stable and predictable schedule to operate smoothly. A validator could even try to “grind” or manipulate their effective balance to influence who becomes the proposer next epoch. Because of these problems, Ethereum needed a way to make the proposer schedule fully deterministic several epochs ahead so it cannot be changed by last-minute EB updates and can be easily accessed by the application layer. N + 1 N N För att genomföra detta introducerar EIP en deterministisk propositor lookahead genom att förbereda och lagra propositor schema för nästa MIN_SEED_LOOKAHEAD + 1 epoker i början av varje epok. som alltid täcker två fulla tidsåldrar av förespråkare - 64 platser totalt. Till exempel, när tidsålder N börjar, innehåller den här listan redan förespråkaren för varje plats i tidsålder N och tidsålder N+1. Sedan, när nätverket flyttar till tidsålder N+1, flyttas listan framåt: förespråkaren poster för tidsålder N tas bort, förespråkare poster för tidsålder N+1 flyttas framåt, och nya förespråkare poster för tidsålder N+2 läggs till i slutet. proposer_lookahead För att hålla detta uppdaterat, flyttar listan framåt vid varje epokgräns: data för tidigare epok tas bort, och en ny uppsättning proposerindex för nästa framtida epok beräknas och bifogas. Processen använder samma frö och effektiva balansregler som tidigare, men nu schemat beräknas tidigare, vilket eliminerar möjligheten för EB-förändringar som påverkar det efter att fröet är känt. Imagine each epoch has 8 slots instead of 32 (just for simplicity). Without this EIP, during epoch 5, you know the seed for epoch 6, but the actual proposer for slot 2 of epoch 6 could still change if a validator gets slashed or earns enough rewards to change their effective balance inside epoch 5. With EIP-7917, at the av epok 5, Ethereum förbereder alla förespråkare för epok 5, 6 och 7 och lagrar dem i ordning inuti Nu, även om balansräkningarna ändras senare i epok 5, förblir förslagsförteckningen för epok 6 fast och förutsägbar. start proposer_lookahead Detta EIP fixar en långvarig övervakning i beacon-kedjedesign. Det garanterar att när RANDAO från tidigare epoker blir tillgänglig kan valideringsvalideringsalternativet för framtida epoker inte ändras. Detta förhindrar också "effektiv balansmjölning", där en validerare försöker justera sin balans efter att ha sett RANDAO för att påverka nästa epoks förespråkarlista. Med deterministisk lookahead elimineras hela angreppsvektorn, vilket gör säkerhetsanalysen mycket enklare. Det ger också konsensuskunder tidig synlighet på vem som kommer att föreslå kommande block, vilket hjälper implementeringar och gör det möjligt för förespråkaren att enkelt verifieras av applikationsskiktet via en Merkle-bevis från beaconroot. The authors considered alternatives, such as caching the effective balances at the start of an epoch, but that would require extra storage and would not expose the schedule to the EVM. They also checked compatibility with future features like Single Secret Leader Election (SSLE). The current design remains compatible because the lookahead could one day store encrypted proposer IDs, or possibly be disabled entirely if SSLE removes lookahead, without breaking anything. Before this proposal, clients only calculated the proposer for the current slot. With EIP-7917, they now compute the proposer list for all slots in the next epoch at once during every epoch transition. This adds a small amount of work, but computing proposer indices is very light and mainly involves sampling validator lists using the seed. However, clients will need benchmarking to make sure this extra computation does not cause performance issues. This EIP does not change how the RANDAO delay works. The proposer lookahead for epoch är fortfarande härrör från RANDAO av epoken . The only change is that effective balances are now aligned with the same delay, so validators cannot modify their EB after seeing the RANDAO result. This removes a potential manipulation strategy, even though no attack had been discovered yet. The deterministic lookahead therefore, strengthens security and prevents malicious alteration of proposer schedules. N N − MIN_SEED_LOOKAHEAD − 1 : Blob base fee bounded by execution cost EIP-7918 Föregående EIP-7918 Ethereum behöver detta förslag eftersom det nuvarande blob-avgiftssystemet (från ) breaks down when execution gas becomes the main cost for rollups. Right now, most rollups pay much more for execution gas (the cost of including their blob transaction in the block) than they pay for the actual blob fee. This creates a problem: even if Ethereum keeps lowering the blob base fee again and again, the rollup’s total cost does not really change, because the expensive part is still the execution gas. Because of this, the blob base fee keeps falling until it reaches the absolute minimum (1 wei), and the protocol can no longer use the blob fee to control demand. Then, when blob usage suddenly goes up, the blob fee needs many blocks to climb back to a normal level. This makes prices unstable and unpredictable for users. EIP-4844 Föreställ dig till exempel att en rollup vill publicera sina data: den betalar cirka 25 000 000 gwei i exekveringsgas (25 gwei per gas för ungefär 1 000 000 gas), medan blob-avgiften bara är cirka 200 gwei. Detta innebär att den totala kostnaden är ungefär 25 000 200 gwei, där nästan hela kostnaden kommer från exekveringsgas, inte blob-avgiften. Om Ethereum fortsätter att sänka blob-avgiften – säg från 200 gwei till 50 gwei, sedan till 10 gwei, och så småningom ner till 1 wei – förändras den totala kostnaden knappt alls, förblir nästan exakt 25 000 000 gwei. Eftersom användare inte känner någon skillnad, ändrar de inte sitt beteende, så protokollet fortsätter att driva ner blob-avgifterna tills de når fixes this by introducing a minimum “reserve price” for blob fees that depends on the execution base fee, preventing blob prices from falling unrealistically low and keeping blob pricing much more stable and predictable for rollups. Föregående EIP-7918 The core idea of EIP-7918 is simple: the price of a blob should never be cheaper than the cost of a certain amount of execution gas (called I EIP är denna konstant inställd på Mekanismen fungerar genom en liten förändring inuti Funktion. Vanligtvis ökar eller minskar denna funktion blobbasavgiften beroende på om blocken använder mer eller mindre blobgas än målet. Med detta förslag, om en blob blir "för billig" jämfört med exekveringsgas, slutar funktionen att subtrahera målblobgasen. Detta gör att överskottsblobgasen växer snabbare, vilket förhindrar att blobbasavgiften sjunker ytterligare. . BLOB_BASE_COST 2¹³ calc_excess_blob_gas() BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB To understand why this is needed, it helps to look at blob demand. A rollup cares about the total price it pays: execution cost plus blob cost. If execution gas fee is very high—for example, 20 gwei—then even if the blob fee drops from 2 gwei to 0.2 gwei, the total cost barely changes. This means reducing the blob base fee has almost no impact on demand. In economics, this is called “ ”Det skapar en situation där efterfrågekurvan är nästan vertikal: sänkning av priset ökar inte efterfrågan. När detta händer blir blobbasavgiftsmekanismen blind – den fortsätter att sänka priset även om efterfrågan inte reagerar. Det är därför blobbasavgiften ofta glider ner till 1 wei. Då, när den verkliga efterfrågan ökar senare, behöver protokollet en timme eller mer av nästan fulla block för att höja avgiften tillbaka till en rimlig nivå. EIP-7918 fixar detta genom att fastställa ett reservpris kopplat till exekveringsgas så att blobavgifterna förblir meningsfulla även när exekveringskostnaderna dominerar. fee inelasticity Another reason for adding this reserve price is that nodes have to do a lot of extra work to verify the KZG proofs for blob data. These proofs are what guarantee that the data inside a blob actually matches its commitment. Under , a node only had to verify one proof per blob, which was cheap. But with (PeerDAS), blobs are broken into many small pieces called cells, and every cell has its own proof. This makes verification much heavier. For example, the execution layer now has to batch-verify 128 proofs for every single blob before a transaction can even enter the mempool—this is about fifteen times more expensive than the normal KZG proof verification that smart contracts pay for. On top of that, full nodes, supernodes, and validators must verify even more proofs depending on how many columns they store or sample. A typical full node must verify proofs for all blobs in the mempool, plus eight sampled columns every slot, plus four columns it permanently custodies. All of this uses real CPU time, and it isn’t free for node operators. If blob fees drop too low, users would get this expensive compute work from the network essentially for free. By linking the blob reserve price to execution gas fees, EIP-7918 makes sure blob users always pay at least a fair minimum amount for the load they put on nodes. Övrigt EIP-4844 EIP-7594 In the long run, EIP-7918 also helps prepare Ethereum for the future. As technology improves, the cost of storing and sharing data naturally gets cheaper, and Ethereum is expected to allow more blob data over time. When blob capacity increases, blob fees (in ETH) should naturally go down. This proposal supports that because the reserve price is tied to execution gas prices, not a fixed number, so it can adjust as the network grows. As both blobspace and execution blockspace expand, their price relationship stays balanced. The only time the reserve price might become too high is in a very unlikely future where Ethereum increases blob capacity a lot but does not increase execution gas capacity. In that case, blob fees might end up higher than needed. But Ethereum is not planning to scale in that way—both blobspace and execution blockspace are expected to grow together. Because of this, the chosen value ( ) is considered safe and well-balanced. BLOB_BASE_COST = 2¹³ Det finns en liten detalj att förstå när exekveringsgasavgifter hoppar plötsligt. Eftersom reservpriset för blob beror på exekveringsbasavgiften kan en plötslig ökning av exekveringsavgifterna tillfälligt driva blobavgifterna till ett tillstånd där exekveringsavgifterna styr dem. Föreställ dig till exempel att exekveringsgasen plötsligt hoppar från 20 gwei till 60 gwei i ett block. Eftersom reservpriset för blob är bundet till det antalet kan blobavgifterna inte falla under den nya högre nivån. Blobavgifterna kommer fortfarande att öka normalt om bloberna används, men protokollet tillåter dem inte att minska förrän de har stigit tillräckligt för att matcha den högre exekveringskostnaden. Detta Författarna utförde också empirisk analys genom att tillämpa reservprisregeln på verklig blobaktivitet från och . During high-execution-fee periods (around ), reserven tröskel signifikant ökade blob basavgiften jämfört med den gamla mekanismen. ), blobavgiften förblev nästan oförändrad utom när den beräknade blobbasavgiften föll under reservpriset. Genom att jämföra tusentals block visar författarna att den nya mekanismen skapar mer stabil prissättning samtidigt som den fortfarande svarar naturligt på efterfrågan. November 2024 March 2025 16 gwei average 1.3 gwei average In terms of security, the change does not introduce any risks. The blob base fee will always settle at or above the cost of units of execution gas. This is safe because the mechanism only raises the minimum fee, and setting a lower bound on pricing does not interfere with protocol correctness. It simply ensures healthy economics. BLOB_BASE_COST : RLP Execution Block Size Limit EIP-7934 EIP-7934 Before EIP-7934, Ethereum did have a strict upper limit on how large an RLP-encoded execution block could be. In theory, a block could become extremely large if it contained many transactions or very complex data. This created two major problems: and . If a block was too large, it would take longer for nodes to download and verify it, which slowed block propagation and increased the chance of temporary blockchain forks. Worse, an attacker could deliberately create a very large block to overload nodes, causing delays or even knocking them offline — a classic denial-of-service scenario. At the same time, Ethereum’s consensus layer (CL) gossip protocol already refused to propagate any block over , vilket innebär att överdimensionerade exekveringsblock kan misslyckas med att sprida sig över nätverket, vilket skapar fragmentering eller noder som inte håller med på kedjan. På grund av dessa risker behövde Ethereum en tydlig, protokollnivåregel för att förhindra överdimensionerade block och hålla nätverket stabilt och säkert. not network instability DoS attack risks 10 MB EIP-7934 löser detta genom att införa en Den maximala tillåtna storleken på en RLP-kodad exekveringsblock ( ) är inställd på , men eftersom beacon block också förbrukar lite utrymme ( Ethereum lägger till en . This means the actual maximum RLP-encoded execution block size allowed is . If the encoded block is larger than this limit, the block is considered and nodes must reject it. With this rule in place, block producers must check the encoded size of every block they build, and validators must verify this limit during block validation. This size cap applies of gas limits -meaning even if a block is “ ” it can still be rejected if its encoded size is too large. This ensures that both gas usage and real byte-size constraints are respected. protocol-level cap MAX_BLOCK_SIZE 10 MiB (10,485,760 bytes) SAFETY_MARGIN 2 MiB (2,097,152 bytes) MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN invalid independently under the gas limit, Choosing a was intentional because it matches the existing constraint in the consensus layer gossip protocol. Anything larger than 10 MiB would not be broadcast across the network anyway, so this EIP brings the execution layer into alignment with the consensus layer’s limits. This creates consistency across all components and prevents situations where a valid execution block becomes “invisible” because the CL refuses to gossip it. 10 MiB cap This change is with blocks larger than the new limit, meaning miners and validators must update their clients to respect the rule. However, since oversized blocks were already problematic and not normal in real operation, the impact is minimal. In terms of security, this EIP significantly strengthens Ethereum against targeted block-size DoS attacks by ensuring no participant can create blocks that overwhelm the network. Overall, EIP-7934 adds an important safety boundary, improves stability, aligns EL and CL behavior, and prevents several classes of attacks related to oversized block creation and propagation. not backward-compatible : Count leading zeros (CLZ) opcode EIP-7939 EIP-7939 Före denna EIP hade Ethereum to count the number of leading zero bits in a 256-bit number. Developers had to implement CLZ manually in Solidity using many bit-shift operations and comparisons. This was a big problem because the custom implementations were och , which increased gas usage. For zero-knowledge proving systems, the cost was even higher — right-shifts are extremely expensive to prove, so operations like CLZ slowed down ZK circuits significantly. Since CLZ is a very common low-level function used in math libraries, compression algorithms, bitmaps, signature schemes, and many cryptographic or data-processing tasks, Ethereum needed a faster and cheaper way to compute it. no built-in opcode slow, expensive used a lot of bytecode EIP-7939 solves this by introducing a . This opcode takes a 256-bit value from the stack and returns the number of leading zero bits. If the input number is zero, the opcode returns , eftersom en 256-bit noll har 256 ledande nollbitar. Detta matchar hur CLZ fungerar i många CPU-arkitekturer som ARM och x86, där denna operation är infödd. , , , olika matematiska funktioner, byte-string-jämförelser, bitmap-skanning, calldata-kompression / dekompression och post-quantum signaturscheman alla dra nytta av snabbare ledande nolldetektering. new opcode called CLZ (0x1e) 256 lnWad powWad LambertW , similar to an , and slightly raised from the old MUL price to avoid underpricing the opcode and causing DoS risks. Benchmarks show that CLZ uses roughly the same compute effort as ADD, and in the SP1 rv32im proving environment, CLZ is actually , reducing ZK proving costs. The EIP also explains why they chose CLZ instead of : du kan beräkna CTZ från CLZ med hjälp av Men du tillförlitligt implementera CLZ med CTZ, så CLZ är mer grundläggande. The gas cost for CLZ is set to 5 ADD cheaper to prove than ADD CTZ (count trailing zeros) x & -x cannot Denna EIP är fullständigt bakåtkompatibel eftersom den introducerar en opcode and does not modify any existing behavior. It also covers edge cases clearly: for example, the opcode returns 256 when the input is zero, and several test cases show inputs like all-zero, top-bit-set, and fully-nonzero values. Since CLZ has predictable and low gas cost, no memory growth, and no state changes, it is safe from denial-of-service issues. new Overall, EIP-7939 makes Ethereum faster, cheaper, and more developer-friendly by adding a simple, efficient primitive that modern CPUs already support — cutting gas, reducing bytecode size, and lowering ZK proving costs for many common operations. : Precompile for secp256r1 Curve Support EIP-7951 Öppna 7951 Before this EIP, Ethereum did have a safe, native way to verify digital signatures created using the . This curve is the standard used in modern devices like På grund av det här saknade stödet kunde appar och plånböcker inte enkelt använda maskinvarusäkerhet på enhetsnivå för att signera. relaterade till punkt till oändlighet hantering och felaktig signatur jämförelse. Dessa problem kan orsaka felaktig verifiering eller till och med risk konsensus misslyckanden. not secp256r1 (P-256) curve Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn security keys two serious security vulnerabilities EIP-7951 fixes those security problems and introduces a safe, native precompile so Ethereum can finally support signatures from modern hardware securely and efficiently. EIP-7951 lägger till en ny På adressen called , som utför ECDSA-signaturverifiering med hjälp av secp256r1-kurvan. Detta gör signaturverifiering snabb och billig jämfört med att implementera algoritmen direkt i Solidity. Precompile använder de officiella kurvparametrarna som definieras av NIST, inklusive fältmodulen, kurvan, baspunkten och undergruppens ordning, vilket säkerställer stark kryptografisk säkerhet. Poäng och skalare kodas i strikt 32-bitars big-endian-format och ett 64-bitars all-zero-värde används för att representera punkten i oändligheten. Precompile förväntar sig exakt —the hash, signature (r, s), and public key coordinates (qx, qy)—and it returns För framgång eller for failure. precompiled contract 0x100 P256VERIFY 160 bytes of input 32 bytes of 1 empty output EIP definierar också strikt . It checks that r and s are within valid ranges, that the public key lies on the curve, and that it is not the point at infinity. If anything is invalid, the precompile returns failure without reverting and consumes the same gas as a successful call. The verification algorithm follows standard ECDSA: it computes s⁻¹ mod n, rebuilds the signing point R’, rejects if R’ is infinity, and finally checks whether the x-coordinate of R’ matches r (mod n). This corrects the mistake in RIP-7212, which compared r’ directly instead of reducing it mod n. input validation rules The secp256r1 curve is fully defined by the following set of parameters: Base field modulus = p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff Curve equation: y^2 = x^3 + ax + b (mod p) Curve coefficient a = 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc Curve coefficient b = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b Base point G: Gx = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296 Gy = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5 Subgroup order = n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 Cofactor = h = 0x1 These parameters are standardized by NIST in SP 800-1861. The gas cost for the operation is set to , vilket är högre än RIP-7212-versionen, men matchar faktiska prestandabegränsningar för secp256r1-verifiering. Viktigt är att gränssnittet förblir fullt kompatibelt med Layer 2-nätverk som redan har implementerat RIP-7212 – samma adress, samma input/output-format – så befintliga smarta kontrakt kommer att fortsätta att fungera utan förändringar. 6900 gas Input: P256VERIFY call excepts 160 Bytes as input that is interpreted as byte concatenation of: 32 bytes ----> message hash (h) 32 bytes ----> signature component (r) 32 bytes ----> signature component (s) 32 bytes ----> public key x-coordinate (qx) 32 bytes ----> public key y-coordinate (qy) Output: will be 32 bytes on successfull verification and 0 bytes on failure Input Validation: The precompile MUST perform the following validation checks and return `` (failure) if any check fails: 1. Input length: Input MUST be exactly 160 bytes 2. Signature component bounds: Both r and s MUST satisfy 0 < r < n and 0 < s < n 3. Public key bounds: Both qx and qy MUST satisfy 0 ≤ qx < p and 0 ≤ qy < p 4. Point validity: The point (qx, qy) MUST satisfy the curve equation qy^2 ≡ qx^3 + a*qx + b (mod p) 5. Point not at infinity: The point (qx, qy) MUST NOT be the point at infinity (represented as (0, 0)) From a security standpoint, the EIP restores proper ECDSA behavior, eliminates malleability concerns at the precompile level (leaving optional checks to applications), and clarifies that constant-time execution is not required for the precompile. The secp256r1 curve provides 128-bit security and is widely trusted and analyzed, making it safe for Ethereum adoption. I korthet, , fix the security issues of the earlier proposal, and provide a reliable, standardized way to verify P-256 signatures across the entire ecosystem. EIP-7951 is needed to safely bring modern hardware-backed authentication to Ethereum Tabellen nedan sammanfattar vilka Ethereum-klienter som behöver genomföra ändringar för varje Fusaka EIP. indikerar att EIP kräver uppdateringar till konsensusskiktsklienter, medan ett kontrollmärke under visar att ändringen påverkar exekveringsskiktsklienter. Vissa EIP:er kräver uppdateringar i båda skikten, medan andra är specifika för bara ett. Consensus Client Execution Client EIP Number EIP Name Consensus Client Execution Client EIP-7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ EIP-7825 Transaction Gas Limit Cap ✅ EIP-7883 ModExp Gas Cost Increase ✅ EIP-7917 Deterministic proposer lookahead ✅ EIP-7918 Blob base fee bounded by execution cost ✅ EIP-7934 RLP Execution Block Size Limit ✅ EIP-7939 Count leading zeros (CLZ) opcode ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ EIP-7594 PeerDAS – Peer Data Availability Sampling ✅ ✅ Öppna 7823 Set upper bounds for MODEXP ✅ Övrigt EIP-7825 Transaktion Gas Limit Cap ✅ EIP-7883 ModExp ökar gaskostnaden ✅ EIP 7917 Deterministisk förespråkare lookahead ✅ Föregående EIP-7918 Blob basavgift begränsad av verkställighetskostnad ✅ EIP 7934 RLP Execution Block Size Limit ✅ EIP 7939 Count leading zeros (CLZ) opcode ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ In summary, these are the key EIPs included in the Fusaka hard fork. While several improvements touch both consensus and execution clients—ranging from gas adjustments and opcode updates to new precompiles—the , which introduces peer-to-peer data availability sampling, enabling more efficient and decentralized handling of blob data across the network. major change of this upgrade is PeerDAS
