Ne váljon kétségbe: A Konstantinápoly és az Ethereum kliensfrissítések kezelésének legjobb gyakorlatai

A szoftverfrissítések, függetlenül attól, hogy eltávolítják a biztonsági hibákat, kijavítanak hibákat vagy új funkciókat adnak hozzá - általában jót tesznek a mindennapi alkalmazásokban, és nem gondoljuk meg kétszer ezen alkalmazást. Az alapvető infrastruktúra-frissítések azonban félelmesek is lehetnek, ha változtatásokat vagy váratlan viselkedést vezetnek be a függő alkalmazásokban, vagy más esetekben, ha a frissítés időben történő elmulasztása törést okozhat. Ez a probléma a kis és nagy entitásokat érinti, és a blokklánc sem kivétel.

Az Alchemy-nál megbízható, méretezhető és gyors Ethereum-infrastruktúrát kínálunk ügyfeleink számára, így nem kell küzdeniük a csomópontok karbantartásával és az alkalmazások felépítésére koncentrálhatnak. Munkánk során sok tanulságot (néha nehéz utat!) Tanultunk arról, hogyan lehet a hálózati villákat és az ügyfélfrissítéseket a legjobban kezelni. A közelgő Konstantinápoly kemény villájával azt gondoltuk, hogy ez remek alkalom lesz a legjobb gyakorlatok megosztására.

Ez az első a sok blogbejegyzés közül, amelyet az Ethereum infrastruktúra megbízható, teljesítő és skálázható módon történő működtetéséről írunk.

Konstantinápoly

A Constantinople az Ethereum következő rendszerszintű frissítése, amely öt EIP-t fog végrehajtani, amely valójában az Ethereum 2.0 felé vezető nagyobb útiterv részét képezi. Rengeteg olyan üzenet létezik, amelyek megvitatják a konkrét változásokat, de a legfontosabb dolog az, hogy mivel ez nem vitatható kemény villa, a közösség elfogadja az új villát, így értéktelenné teszi a tokenjeket és a többi állapotot a nem frissített csomópontokon.

Hogyan befolyásolja ez Önt?

A dapp fejlesztők számára a legfontosabb elvitel az, hogy a csomópontot frissítenie kell egy Constantinople kompatibilis verzióra, vagy pedig nem lesz kompatibilis a hálózat többi részével a korábbi 7 080 000 blokknál. Az Ethereum ügyfelek valószínűleg naprakészek lesznek a lánc kemény villáinál, és jóval a becsült villát dátuma előtt kiadnak stabil, kompatibilis verziójukat, pl. geth és paritás. Ha saját Ethereum kliens csomópontját kezeli, akkor frissítenie kell az ethereum klienst egy olyan verzióra, amely kompatibilis a kemény villával; a paritás 2.1.10-es stabil vagy annál nagyobb, a geth pedig 1.8.20-as vagy annál nagyobb.

A keményvilla frissítéseinek kevés és távol kell lennie, de az Ethereum kliens frissítései sokkal gyakoribbak lehetnek. Ha egy lánctól függő szolgáltatást üzemeltet, akkor az ügyfél naprakészen tartása hasznos lehet a biztonsági hibák kijavításához vagy az új funkciók kiaknázásához. Vigyáznia kell azonban arra, hogy ne vezessen be váratlan kérdéseket alkalmazásába.

Legjobb gyakorlatok

Ha olyan szolgáltatást futtat, amely rendszeres együttműködést igényel az Ethereum blokklánccal, akkor néhány alapvető gyakorlat megmenti a potenciális katasztrófás hibákatól a csomópontok frissítésekor. Áttekintettünk néhány, a rossz frissítésekről szóló való életbeli forgatókönyvet, amelyek lendületet adtak ennek a blogbejegyzésnek.

Több csomópont futtatása

Javasoljuk, hogy a csomópontok futtatása általános bevált gyakorlatként szolgáljon a házon belüli Ethereum infrastruktúra fenntartásához, mivel számos előnye van, beleértve a megnövelt megbízhatóságot és méretezhetőséget. Ez azonban következetességgel és idempotenciával kapcsolatos kérdéseket vehet fel a rendszerében, amelyekkel egy későbbi blogbejegyzésben foglalkozunk.

Frissítések esetén a több csomópont futtatása néhány további előnyt kínál:

  1. Az extra csomópontok biztonsági másolatként szolgálnak arra az esetre, ha egy frissítés rosszul fordul elő, és csomópontot helyrehozhatatlanná tesz
  2. Magas rendelkezésre állás és nincs állásidő a csomópontok folyamatos frissítése közben
  3. Lehetővé teszi a regressziós tesztet, amely összehasonlítja a frissített csomópontokat az eredeti csomópontokkal a várt viselkedés biztosítása érdekében

Egy helyrehozhatatlan csomópont esetén egy új teljes archív csomópont akár két hétig is eltarthat a teljes szinkronizáláshoz. Biztonsági mentés nélkül ez elfogadhatatlanul sok állásidőt jelent.

1. példa: Buggy DB áttelepítés

Az egyik probléma, amelyet a paritás 1.X.X-ről 2.X.X-re történő frissítésekor láttunk, a korrupció volt az adatbázisban. A frissítés egy belső DB áttelepítést tartalmazott, amely tévesen konvertálta a blokkszámokat a bloom szűrőben, ami üres eredményeket eredményezett a getLog kérések számára a korábbi blokkokhoz. Az adatvesztés visszafordíthatatlan volt, így a csomópontot nem sikerült megmenteni. Nagyon szerencsések voltak, hogy egy kanári csomóponton elvégeztük a belső tesztelést, a nem frissített csomópontokra való visszaállítást, hogy rendszereinket folyamatosan tartsuk, és várjuk meg, amíg a paritás csapat a 2.2.3-béta verzióban megoldja a problémát.

Szigorú regressziós tesztelés

A szigorú tesztelést mindig erősen ajánljuk a rendszer bármilyen változása esetén. Ilyen értelemben a csomópontok frissítésekor tesztelni fogja annak ellenőrzését, hogy az alkalmazás és az infrastruktúra továbbra is a várt módon működik-e. Ellenkező esetben a felhasználókat és a rendszereket valószínűleg kikapcsolhatja. Több futó csomóponttal a garantálás legjobb módja az előző stabil csomópontok tesztelése egy frissített kanári csomóponttal szemben. Ha bármilyen törésmódosítást észlel, ellenőrizze, hogy a rendszer biztonságosan kezeli-e azokat a fürt többi részének frissítése előtt.

Ami a regressziós teszteket illeti, egyenesen a forráshoz megyünk azáltal, hogy megismételjük a termelési igényeket a csomópontjainkkal szemben. Ezt manuálisan is el lehet végezni az egyszeri ellenőrzéseknél, de mivel sok projektet támogatunk, kiterjedt automatizált tesztelési keretet építettünk fel, amely a legfrissebb élő kéréseket mintázza, azokat különféle kliens verziókban lejátssza és összehasonlítja az eredményeket. Ez lehetővé teszi számunkra annak ellenőrzését, hogy kódunk biztonságosan együttműködhet-e a frissített csomópontokkal, mielőtt a termelésbe szállítanák. Ez a keret kihasználható a belső kódváltozások regressziós tesztjeire is.

2. példa: A válasz kimeneti formátumának megváltoztatása

Ez egy érdekes kérdés, amellyel szembesültünk, amikor egy újonnan frissített ügyfél eltérő választ adott vissza az EVM végrehajtási hibájára. Az 1.11.1-béta-paritás paritás a következőképpen válaszolt:

{“Jsonrpc”: “2.0”, “hiba”: {“kód”: - 32015, “üzenet”: “virtuális gép végrehajtási hibája.”, “Data”: “Reverted 0x”}, “id”: 1}

A korábbi verziók válaszai helyett, amelyek így néztek ki:

{ „Jsonrpc”:”2.0" ,” id”: 1,” eredmény”:” 0x”}

A válasz formátumának megváltoztatása valójában előnyös, mivel több végrehajtási részleteket gyűjt fel a hívó fél számára, nem pedig csendesen kudarcot okoz, de problémákat okozhat, ha a kódot nem úgy állították be, hogy kezelje. Ebben a forgatókönyvben a válaszkimenetek összehasonlítása felvette a változást, és egyszerűen frissítettük rendszereinket, és figyelmeztettük ügyfeleinket, hogy az új válasz ne aggódjon, és szolgáltatásaikat összeegyeztethetővé tegyük.

Építeni!

Reméljük, hogy ez hasznos volt, és hogy ezek a bevált gyakorlatok fájdalommentessé teszik a csomópontfrissítéseket az Ön számára a jövőben. Segítettek nekünk abban, hogy a frissítések mindig zavartalanul működjenek mind a saját rendszereink, mind az ügyfeleink számára, akik ránk támaszkodnak. Tudjuk, hogy milyen nehézek lehetnek a csomópontok karbantartása és méretezése, és meg akarjuk terjeszteni az évek során megszerzett tapasztalatainkat.

Ha egy Ethereum projekten dolgozik, és nem akarja foglalkozni a csomópontok karbantartásának általános költségeivel, beszéljen velünk! Az Alchemy szolgáltatásként a leggyorsabb, méretezhetőbb és legmegbízhatóbb Ethereum infrastruktúrát nyújtja, így összpontosíthat termékének felépítésére. A motorháztető alatt az Alchemy forradalmian új infrastruktúrát épített fel, amely már olyan hatalmas blokklánc-projekteket hajt végre, mint például az Augur, a legfontosabb blockchain-cégeket, mint például a CryptoKitties, és a legfelső hedge-alapokat (több mint 3 milliárd dollárt kezelve). Tudjon meg többet az alchemyapi.io oldalon.