Ethereumin seuraavalla suurella päivityksellä on uusi päivämäärä kalenterissa, vaikka kyseessä ei olekaan mainnet-julkaisu. Kehittäjät ovat aikatauluttaneet Glamsterdam-päivityksen aktivoitumaan Hoodi-testiverkossa 26. lokakuuta, mikä on jälleen yksi askel testattaessa muutoksia siihen, miten Ethereum tuottaa lohkoja ja huomioi suorituskustannukset. TL;DR: Glamsterdam on aikataulutettu Hoodiin 26. lokakuuta kello 17:42:48 UTC. Testiverkon gas-raja nousee 200 miljoonaan samaan aikaan, mutta Ethereum ei ole ilmoittanut mainnet-aktivointipäivämäärää. Ethereum Foundation kertoo, että päivitys aktivoituu Hoodin epookissa 132 352, slottissa 4 235 264. Se seuraa päivityksen 6. lokakuuta tapahtunutta aktivointia Sepoliassa, mikä antaa kehittäjille vielä yhden ympäristön tarkistaa ohjelmistojen yhteensopivuus ennen päivämäärän valitsemista pääketjulle. Kaksi muutosta on Glamstedamin ytimessä. Enshrined proposer-builder separation eli ePBS siirtää lohkoehdotajien ja -rakentajien välisen suhteen Ethereumin protokollaan sen sijaan, että nojattaisiin niin vahvasti ulkopuolisiin järjestelyihin. Lohkotason käyttölistojen on tarkoitus helpottaa asiakkaita käsittelemään ja validoimaan lohkon osia rinnakkain. Päivitys muuttaa myös gas-kirjanpitoa, mukaan lukien sitä, miten Ethereum veloittaa tilan luomisesta ja käytöstä. Tällä on merkitystä sovelluskehittäjille, joiden sopimukset tai työkalut nojaavat kiinteisiin oletuksiin gas-kustannuksista. Hoodin validaattorit ja solmujen ylläpitäjät tarvitsevat puolestaan yhteensopivat suoritus- ja konsensusasiakkaat ennen aktivointia. 200 miljoonan gas-raja testiverkossa on tärkeä insinöörityön virstanpylväs, ei lupaus siitä, että mainnetin kapasiteetti nelinkertaistuisi välittömästi. Hoodi-harjoitus auttaa määrittämään, käyttäytyvätkö suunnitellut muutokset odotetusti todellisissa käyttöolosuhteissa. Mainnetin käyttäjillä ei ole vielä mitään toimenpiteitä tehtävänä. Kirjoittanut News Desk ja muokannut Samuel Rae.
Usein kysytyt kysymykset
UKK Ethereumin 26. lokakuuta Hoodi-testi Glamsterdamille ja 200 miljoonan gas-rajalle
1 Mikä on 26. lokakuuta tehtävä Hoodi-testi
Se on testiverkkotesti Hoodissa, yhdessä Ethereumin testiverkoista, jossa kehittäjät kokeilevat Glamsterdam-päivitystä ennen sen julkaisua mainnetissa. Ajattele sitä kenraaliharjoituksena
2 Mikä on Glamsterdam-päivitys
Se on Ethereumin seuraava suuri päivitys, joka yhdistää Gloasin ja Amsterdamin työn. Nimi on näiden kahden yhdistelmä
3 Mikä on gas-raja
Gas mittaa laskennallista työtä Ethereumissa. Gas-raja on suurin sallittu gas-määrä lohkoa kohden – se rajoittaa, kuinka paljon työtä lohko voi sisältää
4 Mitä 200 miljoonan gas-raja tarkoittaa
Se tarkoittaa, että lohkot voisivat käsitellä jopa 200 miljoonaa gasia, mikä on karkeasti useita kertoja nykyiset rajat. Suuremmat lohkot tarkoittavat enemmän transaktioita lohkoa kohden ja mahdollisesti alhaisempia maksuja
5 Miksi 200 miljoonan gas-raja on iso juttu
Se on merkittävä parannus kapasiteettiin. Se voisi lisätä läpimenoa ja vähentää ruuhkaa, mutta se myös rasittaa solmujen kaistanleveyttä ja tilan kasvua – juuri siksi sitä testataan huolellisesti
6 Miksi testata Hoodissa mainnetin sijaan
Testiverkot antavat kehittäjien löytää virheitä vaarantamatta oikeita varoja. Hoodi on yksi Ethereumin nykyisistä pitkäaikaisista testiverkoista, joita käytetään panostukseen ja päivitysten kenraaliharjoituksiin
7 Mitä tapahtuu, jos testi epäonnistuu
Kehittäjät diagnosoivat ongelmat, paikkaavat asiakasohjelmat ja suorittavat testit uudelleen. Epäonnistunut testiverkkotesti viivästyttää mainnet-aikataulua, mutta ei vaikuta oikeiden käyttäjien varoihin
8 Pitääkö minun tehdä jotain tavallisena käyttäjänä
Ei. Testiverkkotestit eivät vaikuta mainnetin ETH:hen tai lompakkoihisi. Pysy vain kuulolla virallisista ilmoituksista mainnetin aikataulusta
9 Ylläpidän solmua – pitäisikö minun välittää
Kyllä. Korkeammat gas-rajat tarkoittavat enemmän CPU:n, muistin, kaistanleveyden ja levyn käyttöä. Seuraa asiakasohjelmien julkaisutietoja ja testaa asetuksesi Hoodissa, jos voit
10 Mitä ongelmia testin aikana voi ilmetä
Yleisiä ovat asiakasohjelmien yhteensopimattomuudet, ohitetut slotit, synkronointiongelmat, lohkojen hitaampi leviäminen ja tilan kasvu