Oppstarten av Berlin, det andre trinnet av Istanbul-oppgraderingen, skal skje på et tidspunkt i 2020. Ethereum-kjerneutviklere delte Istanbul inn i to faser fordi to av EIP-ene som diskuteres, krever omfattende testing og utvikling før lansering. Foreløpig har kjerneutviklere godkjent og løftet to EIP-er til godkjent status. Det er to andre foreslåtte EIP-er som kanskje er klare til Berlin.

Godkjent: EIP-2315 implementerer enkle delrutiner for EVM som kan redusere gasskostnadene og gjøre tilstandsanalyse enklere. EIP 2537 (som erstattet EIP-1962) implementerer en enkelt BLS-kurve for å gjøre utrulling og håndtering av rullekontrakter og zk-SNARKs / STARKs lettere.

Foreslått: EIP-2046 reduserer gasskostnadene for statiske samtaler til forhåndsindvidualiserte kontrakter. EIP-2565 vil ompriset ModExp-forberedelsesskriftet (EIP-198) for å muliggjøre mer kostnadseffektiv verifisering av RSA-signaturer, verifiserbare forsinkelsesfunksjoner (VDF-er) og primtallsjekker, blant andre funksjoner.

Istanbul fase II utelater bemerkelsesverdig alle EIP-er knyttet til vanskelighetsbomben (dvs. Ethereum "isbreen"). Kjerneutviklerne konkluderte med at "det ikke er noen større grunn til å gjøre det nå" fordi vanskelighetsbomben bare er nødvendig når Ethereum 2.0 og dens Proof-of-Stake (PoS)-konsensusmekanisme er aktivert. Å overse en Ice Age EIP for øyeblikket unngår også ytterligere forsinkelser i Berlins utviklingsfase.

Kjerneutviklere og den større Ethereum-fellesskapet utelukker også EIP-1057, forslaget til den nå beryktede ProgPoW (forkortelse for Progressiv Proof-of-Work). Den hadde som mål å endre Ethereum's hashing-algoritme for å lukke ytelseseffektivitets gapet mellom generaliserte og spesialiserte gruve-maskinvare (også kjent som ASIC-er). Mens GPU-gruvearbeidere og noen kjerneutviklere støttet forslaget, var mange i fellesskapet sterkt imot det. Derfor er alle sider enige om "ikke å inkludere ProgPoW" i kommende forgreninger, da ingen protokollendringer er verdt å utløse en nettverkssplitting.

Lær mer: Berlin EIPs regneark

EIP-1559 ble skrevet av Vitalik Buterin og Eric Conner, blant andre. Målet er å erstatte Ethereum's "first-price auction" gebyrmodell med et grunnleggende nettverksgebyr som kan endres basert på nettverks etterspørsel. Målet er å skape en mer effektiv gebyrmarkedsføre og forenkle gassbetalingsprosessen for klient og applikasjonsprogramvare, fjerne muligheten for at brukere må betale unødvendig høye gassavgifter. EIP-1559 foreslår også å brenne det grunnleggende nettverksgebyret for å hjelpe til med å holde dette gebyret lavt og ETH-inflasjon i sjakk.

Fase 1 vil introdusere 64 uavhengige shard-kjeder til ETH 2.0-nettverket. Shard-kjeder vil ikke utføre tilstand eller holde oversikt over kontosaldoer, da fasen kun har til hensikt å teste konstruksjonen og gyldigheten til shard-kjedene med Beacon-kjeden. ETH 1.0 vil fortsette å kjøre parallelt med ETH 2.0 gjennom denne fasen.

Et forslag om å slå sammen den nåværende Ethereum-nettverket med Ethereum 2.0 ble først introdusert av Vitalik Buterin. Forslaget har til hensikt å fjerne Proof-of-Work (PoW) kjeden ved å flytte alt til Beacon Chain på en akselerert tidsplan. Denne akselererte fusjonen krever stateless klienter på Ethereum 1.x, noe som vil fjerne behovet for at de fleste noder lagrer hele staten sammenlagt.

Den endelige fasen av Serenity vil legge til full funksjonalitet til shard chains, slik at de kan utføre transaksjoner og opprettholde kontosaldoer. Den introduserer også eWASM virtuell maskin, som vil erstatte EVM.

Olympic var den endelige Ethereum-prøvekonseptet som ble lansert før hovednettet ble lansert. Dens erklærte formål var å belønne deltakere for å teste grensene for Ethereum-design ved å "spamme nettverket med transaksjoner og gjøre gale ting med statusen." Arrangementet inkluderte en konkurranse som tilbød en pool på 25 000 ETH (ca. 0,03% av Ethereums initielle tilbud) for de beste gruvearbeidere og utviklerdeltakerne. Bred testnett-engasjement avdekket kritiske feil og enkle optimaliseringer i det levende systemet som kjerne-teamet var i stand til å identifisere og løse før hovednettet. Ethereum-kjerneutviklere deprecated Olympic når Frontier ble lansert til fordel for Mordon, den Frontier-tilsvarende offentlige testnettet.

Frontier markerte den offisielle 1.0-utgivelsen av Ethereum hovednettverket og introduserte en rekke nye egenskaper, inkludert en blokkbelønning, en midlertidig gasblokkgrense og Canary-kontrakter. Frontier-lanseringen gjorde det mulig for gruvearbeidere å begynne å motta ekte ETH som belønning for innsatsen sin, med den første blokksubsidien bestående av fem ETH per gyldig blokk. Versjon 1.0 hadde også en innkodet gasgrense på 5000 gas per blokk for å unngå problemer med nodeinstallasjon. Gassgrensen varte bare noen få dager etter lanseringen før den ble fjernet automatisk. For å unngå uønskede chaintafs, inneholdt Frontier også Canary-kontrakter. Canary-kontrakter ga Ethereum-kjerneutviklere evnen til å stoppe spesifikke operasjoner eller transaksjoner før en gruvearbeider vandret av til en forlatt blockchain. Disse kontraktene betydde at den endelige utførelsen av transaksjoner forble sentralisert i Ethereums tidlige stadier.

Homestead var den første planlagte hardgaffelen av Ethereum og fant sted ved blokknummer 1 150 000. Oppgraderingen fjernet Canary-kontraktene som ble brukt i Frontier, og eliminerte dermed den sentraliserte prosessen for utførelse av transaksjoner, samtidig som nå mye brukte Solidity-smartkontrakter ble introdusert. Det inkluderte også (nå utdatert) Mist-lommeboken, det første brukergrensesnittet (UI) for lagring og transaksjon av tokens, samt skriving og distribusjon av smartkontrakter.

Videre var Homestead en av de første implementeringene av Ethereum Improvement Proposals (EIP-er), og oppgraderingen introduserte tre nye EIP-er ved aktivering: EIP-2 (som inkluderte underforslagene EIP-er 2.1-2.4) sikret ACID-overholdelse (alt eller ingenting) for kontraktsutplasseringer og bidro til å stabilisere blokkeringstider EIP-7 la til DELETECALL-opcode EIP-8 utstyrt klientprogramvaren med evnen til å tilpasse fremtidige nettverksprotokolloppdateringer

Den "Spurious Dragon" hard-gaffelen ble aktivert ved blokk 2,675,000, som ankom 22. november 2019. Oppgraderingen introduserte fire kodeendringer: EIP-155 tilbød beskyttelse mot omstartangrep EIP-160 økte prisen på EXP-opkoden for å gjøre det vanskeligere å bremse nettverket med beregningsintensive operasjoner EIP-161 gjør det mulig å fjerne store mengder tomme kontoer for å redusere blockchain-tilstanden EIP-170 setter en grense for kodesiden en smart kontrakt kan inneholde for å hindre repetitive angrep på store kodelupper.

Byzantium var den første fasen av den foreslåtte Metropolis-oppgraderingen og ble aktivert på blokk 4 370 000. Byzantium-straffen inkluderte ni EIP-er, der EIP-100, EIP-658 og EIP-649 introduserte de mest betydelige kodeendringene. EIP-100 justerte vanskelighetsformelen for å stabilisere ETH-utstedelsesraten. EIP-658 la til et nytt felt i transaksjonskvitteringer for å indikere suksess eller feil. EIP-649 forsinket vanskelighetsbomben (dvs. Ethereum "is-aldersperioden") med ett år og redusererte blokksubsidiet fra fem til tre ETH. Detaljer om de gjenværende Byzantium EIP-ene er tilgjengelige her.

Constantinople, den andre fasen av Metropolis, var opprinnelig planlagt å bli utgitt ved blokk 7,080,000 (16. januar 2019). Men den 15. januar 2019, oppdaget sikkerhetsrevisjonsfirmaet ChainSecurity en sårbarhet i en av de aksepterte EIPs som ville muliggjøre en re-angrepsangrep (dvs. en mulighet for en angriper å stjele brukerfond, lignende The DAO-hacket). Kjerneutviklere for Ethereum og noen prosjekter som kjører på nettverket stemte for å utsette Constantinople til utviklerne lukket sikkerhetshullet.

Etter en måned lang forsinkelse gikk Constantinople og dens sikkerhetsoppdatering, St. Petersburg, live ved blokk 7,280,000, og introduserte fem nye kodeendringer til nettverket: EIP-145 la til bitwise-shifting-instruksjoner til EVM, som gjorde gjennomføringen av skift i smarte kontrakter betydelig rimeligere EIP-1052 fremskyndet verifikasjon mellom smarte kontrakter (smarte kontrakter kan verifisere hverandre via en hash i stedet for hele kodesettet) EIP-1014 forbedret tilkoblingen av tilstandskanaler for å lette forbindelsen til off-chain-skalering EIP-1283 reduserte kostnadene for å utføre flere oppdateringer innen en enkelt transaksjon (også kjent som SSTORE-opcode) EIP-1234 forsinket vanskelighetsbomben i ett år, og reduserte belønningen for gruvedrift fra tre til to ETH per blokk (reduksjonen er også kjent som "Thirdening")

Første fase av Istanbul er satt til å aktiveres ved blokk 9 069 000, nesten to måneder etter den opprinnelig planlagte lanseringsdatoen (16. oktober 2019). Istanbul fase I har som mål å introdusere seks nye EIP-er ved aktivering, for å bidra til å optimalisere opcode-beregningkostnader, forbedre sikkerheten mot Denial-of-Service-angrep og forbedre ytelsen til lag-2-løsninger ved å bruke a href=""ZK-SNARKs/a eller a href=""ZK-STARKs/a, ved hjelp av andre fremskritt. De aksepterte EIP-ene inkluderer: EIP-152 legger til muligheten for å verifisere atomutveksling mellom Zcash og Ethereum EIP-1108 reduserer kostnadene for ZK-SNARKs EIP-1344 forbedrer smartkontrakters mulighet, spesielt de som brukes av lag-2-løsninger, for å spore riktig basekjede under en hard gaffel EIP-1844 omstrukturerer kostnadene for spesifikke a href=""Ethereum Virtual Machine (EVM)/a opcode for å motvirke spamangrep og for å matche hvert trinn med den nødvendige beregningsnivået EIP-2028 reduserer kostnaden ved å kalle data innen transaksjoner og gebyrene knyttet til ZK-SNARKs og ZK-STARKs EIP-2200 endrer kostnadene for lagring i EVM og lar smartkontrakter generere mer kreative funksjoner.

Muir-breen hard fork ble aktivert ved blokk 9 200 000, som ankom Jan. 2, 2020. Oppgraderingen inkluderte bare EIP-2384, som forsinket Ethereums iboende "Difficulty Bomb" med ytterligere 4 000 000 blokker (ca. 611 dager), for å forhindre blokk-tider fra å øke (og brukbarhet synke). Muir-breen sin brå ankomst, mindre enn en måned etter Istanbul, markerte tredje gang Ethereum-kjerneutviklerne valgte å utsette Difficulty Bomb (også kjent som Ice Age).

Lær mer: Ethereum Muir Glacier Upgrade av Ethereum Cat Herders

Serenity Fase 0 markerer Ethereum sin initiale overgang til Ethereum 2.0. Denne første fasen vil introdusere Beacon Chain, som vil fungere som ryggraden i Ethereum 2.0 sine sharded nettverksarkitektur. I motsetning til Ethereum sin nåværende Proof-of-Work (PoW) blokkjede, vil Beacon Chain bruke Casper FFG, en spesifikk variant av Proof-of-Stake (PoS), og et system av valideringer for å bekrefte transaksjoner og hindre Sybil-angrep.

Ethereum-utviklere har delt Serenity-oppgraderingen inn i tre faser for å optimalisere utviklingsprosessen og begrense utplasseringsrisikoene. Spesifikasjonene for denne første fasen inkluderer: Beacon Chain er kjernen i Ethereum 2.0 systemet; det administrerer PoS-protokollen for seg selv og alle de individuelle shard-kjedene. Beacon Chain vil bruke Casper the Friendly Finality Gadget (Casper FFG) for å sikre transaksjonsfullføringsenhet. Fork Choice gjør det mulig for valideringens klienter å automatisk velge riktig kjede når fasen 0 Serenity fork blir initiert. Deposit Contract lar Ethereum interessenter overføre midler fra ETH 1.0 til ETH 2.0 og kreve rettigheter til en validering rolle på den nye PoS-kjeden. Honest Validator dikterer den forventede oppførselen til en "ærlig validering og slasher-spesifikasjoner med hensyn til fase 0 av ETH 2.0.

Det er essensielt å merke seg at lanseringen av Fase 0 ikke umiddelbart vil erstatte Ethereum 1.0 (også kjent som Ethereum 1.x). De to kjedene vil eksistere samtidig i alle fall frem til Serenity Fase 1.5 ankommer, som markerer når den nåværende Ethereum kjeden vil smelte sammen med Ethereum 2.0 systemet en shard innenfor nettverket. Å kjøre den gamle og fremtidige kjeden parallelt kan føre til at ETH inflasjonen øker, siden begge kjedene samtidig vil mynte nye tokens.