Starten av Berlin, det andra steget av Istanbul-uppgraderingen, borde ske någon gång under 2020. Ethereums kärnutvecklare delade upp Istanbul i två faser eftersom två av de EIP:er som diskuterades kräver omfattande testning och utveckling innan lansering. För närvarande har kärnutvecklarna godkänt och höjt två EIP:er till accepterat status. Det finns två andra föreslagna EIP:er som kanske är redo i tid för Berlin.

Accepterade EIP-2315 implementerar enkla delrutiner för EVM som kan sänka gasavgifterna och göra statliga analyser enklare EIP 2537 (som ersatt EIP-1962) implementerar en enda BLS-kurva för att göra det enklare att distribuera och hantera rollup-kontrakt och zk-SNARKs/STARKs.

Föreslagna EIP-2046 minskar gasavgiften för statiska samtal som görs till förkompilerade kontrakt EIP-2565 omprisar ModExp-förkompileringen (EIP-198) för att möjliggöra mer kostnadseffektiv verifiering av RSA-signaturer, verifierbara fördröjningsfunktioner (VDF:er) och primtalstester, bland annat funktioner.

Istanbul fas II utesluter märkbart alla EIP:er relaterade till svårighetsbomben (dvs Ethereum "istiden"). Kärnutvecklarna drog slutsatsen att "det inte finns någon större anledning att göra det nu" eftersom svårighetsbomben endast är nödvändig när Ethereum 2.0 och dess Proof-of-Stake (PoS)-konensusmekanism aktiveras. Att för närvarande inte inkludera någon Istids-EIP undviker även ytterligare förseningar i Berlins utvecklingsfas.

Kärnutvecklare och den större Ethereum-gemenskapen utesluter också EIP-1057, förslaget till den nu ökända ProgPoW (förkortning för Progressive Proof-of-Work). Syftet var att ändra Ethereums hashningsalgoritm för att stänga prestandaeffektivitetsgapet mellan allmän och specialiserad gruvhårdvara (även känd som ASIC). Medan GPU-gruvarbetare och vissa kärnutvecklare gillade förslaget var många i samhället starkt emot det. Därför är alla överens om att inte inkludera ProgPoW i några kommande gafflar, eftersom inga protokolländringar är värda att utlösa en nätverkssplittring.

Lär dig mer: Berlin EIP:er kalkylblad.

EIP-1559 skrevs av Vitalik Buterin och Eric Conner, bland andra. Dess syfte är att ersätta Ethereum's "förstaprisauktion" avgiftsmodell med en basnätverksavgift som kan ändras beroende på nätverksbehov. Målet är att skapa en mer effektiv avgiftsmarknad och förenkla den gasbetalningsprocessen för klient- och applikationsprogramvara genom att ta bort möjligheten för användare att betala onödigt höga gasavgifter. EIP-1559 föreslår också att bränna den basnätverksavgiften för att hjälpa till att hålla denna avgift låg och ETH-inflationen under kontroll.

Fas 1 kommer att införa 64 oberoende shard-kedjor till ETH 2.0 nätverket. Shard-kedjor kommer inte att utföra tillstånd eller hålla koll på kontosaldo, eftersom fasen avser att endast testa konstruktionen och giltigheten av shard-kedjor med Beacon-kedjan. ETH 1.0 kommer fortsätta att köras parallellt med ETH 2.0 under denna fas.

Ett förslag om att slå samman den nuvarande Ethereum-nätverket med Ethereum 2.0 först introducerat av Vitalik Buterin. Förslaget avser att ta bort Proof-of-Work (PoW)-kedjan genom att flytta allt till Beacon Chain på en accelererad tidsplan. Denna accelererade sammanslagning kräver stateless-klienter på Ethereum 1.x, vilket skulle ta bort behovet av att de flesta noder lagrar hela staten helt och hållet.

Den sista fasen av Serenity kommer att ge full funktionalitet till skardkedjor, vilket gör det möjligt för dem att utföra transaktioner och upprätthålla kontoavgifter. Dessutom introducerar den eWASM virtuella maskinen, som kommer att ersätta EVM.

Olympic var den sista Ethereum proof-of-concept som släpptes innan huvudnätets lansering. Dess uttalade syfte var att belöna deltagare för att testa gränserna för Ethereum design genom att 'spamming nätverket med transaktioner och göra galna saker med tillståndet.' Evenemanget innefattade en tävling som erbjöd en pool av 25 000 ETH (ca 0,03% av Ethereum's initiala tilldelning) för toppgruvearbetare och utvecklare. Omfattande testnet-engagemang avslöjade viktiga buggar och enkla optimeringar i det levande systemet som kärnteamet kunde identifiera och lösa innan huvudntet lanserades. Ethereum kärnutvecklare föråldrade Olympic när Frontier lanserades till förmån för Mordon, den Frontier-ekvivalenta offentliga testnet.

Frontier markerade den officiella 1.0-versionen av Ethereum huvudnät och introducerade en serie nya funktioner, inklusive en blockbelöning, en tillfällig gasblockeringsgräns och Canary-kontrakt. Frontier-lanseringen gjorde det möjligt för gruvarbetare att börja ta emot riktiga ETH som belöning för deras ansträngningar, med den initiala blocksubventionen bestående av fem ETH per giltigt block. Version 1.0 hade också en hårdkodad gasgräns på 5000 gas per block för att förhindra eventuella problem med nodinstallationen. Gasgränsen höll bara i några dagar efter lanseringen innan den automatiskt togs bort. För att undvika oönskade kedjeförgreningar innehöll Frontier även Canary-kontrakt. Canary-kontrakt gav Ethereum-kärnutvecklare möjlighet att stoppa specifika operationer eller transaktioner innan en gruvarbetare avvek till en föräldralös kedja. Dessa kontrakt innebar att den slutliga utförandet av transaktioner förblev centraliserad i Ethereum's tidiga stadier."

Homestead var den första planerade hårda gaffeln av Ethereum och ägde rum vid blocknummer 1 150 000. Uppgraderingen tog bort Canary-kontrakten som användes i Frontier och eliminerade därmed den centraliserade processen för att utföra transaktioner. Istället introducerades Solidity smarta kontrakt som nu används i stor utsträckning. Homestead inkluderade också (nu föråldrade) Mist-plånboken, den första användargränssnittet (UI) för att lagra och genomföra transaktioner av tokens, samt skriva och distribuera smarta kontrakt.

Vidare var Homestead en av de första implementeringarna av Ethereum Improvement Proposals (EIP) och uppgraderingen introducerade tre nya EIP:er vid aktivering: EIP-2 (som inkluderade del-förslagen EIP-2.1-2.4) säkerställde ACID-kompatibilitet (allt-eller-inget) för kontraktsdistributioner och bidrog till att stabilisera blocktider. EIP-7 lade till DELETECALL-opkoden. EIP-8 utrustade klientprogramvaran med förmågan att ta hänsyn till framtida nätverksprotokolluppdateringar.

Den falska draken-hårdgaffeln aktiverades vid block 2 675 000, som anlände den 22 november 2019. Uppgraderingen införde fyra kodändringar: EIP-155 erbjöd skydd mot upprepade attacker EIP-160 ökade priset på EXP-opkoden för att göra det mer utmanande att sakta ned nätverket med beräkningsintensiva operationer EIP-161 gör det möjligt att ta bort stora mängder tomma konton för att minska blockchainens storlek EIP-170 ställde in en begränsning för kodstorleken som en smart kontrakt kan innehålla för att förhindra repetitiva attacker på stora kodstycken.

Byzantium var den första fasen av den föreslagna Metropolis-uppgraderingen och aktiverades vid block 4 370 000. Byzantium hard fork inkluderade nio EIP:er, där EIP-100, EIP-658 och EIP-649 introducerade de mest betydande kodändringarna. EIP-100 justerade svårighetsformeln för att stabilisera utgivningshastigheten av ETH EIP-658 lade till ett nytt fält i transaktionskvitton för att indikera framgång eller misslyckande EIP-649 försenades svårighets-bomben (dvs Ethereum "isåldern") med ett år och minskade blocksubventionen från fem till tre ETH. Detaljer om de återstående Byzantium EIP:erna finns här.

Konstantinopel, den andra fasen av Metropolis, var ursprungligen planerad att lanseras vid block 7,080,000 (16 januari 2019). Men den 15 januari 2019 upptäckte revisionsfirman ChainSecurity en sårbarhet i en av de accepterade EIP:erna som skulle möjliggöra en reentrancy attack (dvs möjligheten för en angripare att stjäla användarfonder liknande The DAO-hacket). Kärn-Ethereum-utvecklare och vissa projekt som körs på nätverket beslutade att skjuta upp Konstantinopel tills utvecklarna stängde säkerhetsluckan.

Efter en månad försening lanserades Konstantinopel och dess säkerhetspatch, St. Petersburg, vid block 7,280,000, vilket införde fem nya kodändringar i nätverket: EIP-145 lade till Bitvis skiftinstruktioner till EVM, vilket gjorde utförandet av skift i smarta kontrakt betydligt billigare EIP-1052 påskyndade inter-smarta kontraktsverifieringar (smarta kontrakt kan verifiera varandra via en hash istället för hela koduppsättningen) EIP-1014 förbättrade integreringar av state channels för att underlätta anslutningen till skalningslösningar utanför kedjan EIP-1283 minskade kostnaderna för att utföra flera uppdateringar inom en enda transaktion (även känd som SSTORE-opcode) EIP-1234 sköt upp svårhetsbombsplatsen (difficulty bomb) för ytterligare ett år och minskade gruvbelöningen från tre till två ETH per block (minskningen är också känd som "Tredjanden")

Fas I av Istanbul kommer att aktiveras på block 9 069 000, nästan två månader efter dess ursprungligt schemalagda lansering (16 oktober 2019). Istanbul Fas I avser att introducera sex nya EIP:er vid aktivering för att hjälpa till att optimera opcode-beräkningskostnader, förbättra säkerheten för denial-of-service-attacker och förbättra prestandan för lager-2-lösningar som använder a href=" "ZK-SNARKs/a eller a href=" "ZK-STARKs/a, bland andra förbättringar. De godkända EIP:erna inkluderar: EIP-152 lägger till förmågan att verifiera atomiska byten mellan Zcash och Ethereum EIP-1108 minskar kostnaderna för ZK-SNARKs EIP-1344 förbättrar smarta kontrakts förmåga, särskilt de som används av lager-2-lösningar, för att spåra den korrekta bas-kedjan under en hård gaffel EIP-1844 omstrukturerar kostnaderna för specifika a href=" " Ethereum Virtual Machine (EVM) /a opcodes för att avskräcka spamattacker och matcha varje operation med dess krävda nivå av beräkning EIP-2028 minskar kostnaden för att hämta data inom transaktioner och avgifterna för ZK-SNARKs och ZK-STARKs EIP-2200 ändrar kostnaden för lagring i EVM och tillåter smarta kontrakt att generera mer kreativa funktioner.

Muir Glacier hårdforken aktiverades vid block 9 200 000, som anlände den 2 januari 2020. Uppgraderingen inkluderade endast EIP-2384, vilket försenar Ethereum nedsättande "Svårighetsbomb" med ytterligare 4 000 000 block (ungefär 611 dagar) för att förhindra att blocktider ökar (och användbarhet sjunker). Muir Glaciers plötsliga ankomst, mindre än en månad efter Istanbul, markerade den tredje gången Ethereum-kärnutvecklare valde att skjuta upp Svårighetsbomben (även känd som Ice Age).

Läs mer: Ethereum Muir Glacier-uppgradering av Ethereum Cat Herders

Serenity Fas 0 markerar Ethereum's inledande övergång till Ethereum 2.0. Denna inledande fas kommer att introducera Beacon Chain, vilken kommer att fungera som ryggraden för Ethereum 2.0's flerfragmenterade nätverksarkitektur. Till skillnad från Ethereum's nuvarande Proof-of-Work (PoW) blockchain, kommer Beacon Chain att använda Casper FFG, en specifik variation av Proof-of-Stake (PoS), och ett system av validerare att bekräfta transaktioner och hämma Sybil attacker.

Ethereum-kärnutvecklarna delade upp Serenity-uppgraderingen i tre faser för att optimera utvecklingsprocessen och begränsa deployeringsriskerna. Specifikationerna för denna första fas inkluderar: Beacon Chain är kärnan i Ethereum 2.0 system; det hanterar PoS-protokollet för sig själv och alla individuella shard-kedjor. Beacon Chain kommer att använda Casper the Friendly Finality Gadget (Casper FFG) för att säkerställa transaktionsfinalitet. Fork Choice möjliggör för validerar-klienter att automatiskt välja rätt kedja när Serenity-forket för Fas 0 initieras. Depositionskontraktet möjliggör för Ethereum-stakeholders att överföra medel från ETH 1.0 till ETH 2.0 och hävda rättigheter till en validerarroll på den nya PoS-kedjan. Honest Validator dikterar det förväntade beteendet för en ”ärlig validator och slashed specifikationer med avseende på Fas 0 på ETH 2.0.

Det är viktigt att notera att lanseringen av Fas 0 inte omedelbart kommer att ersätta Ethereum 1.0 (även känt som Ethereum 1.x). De två kedjorna kommer att samexistiera åtminstone tills Serenity Fas 1.5 kommer, vilket markerar när den nuvarande Ethereum-kedjan kommer att sammanfogas in i Ethereum 2.0 systemet en shard inom nätverket. Att köra de gamla och framtida kedjorna parallellt kan orsaka att ETH-inflationen ökar eftersom båda kedjorna samtidigt kommer att prägla nya tokens.