Ikke bli gnidd: beste fremgangsmåter for håndtering av oppgraderinger av Konstantinopel og Ethereum

Programvareoppdateringer, enten det er å plugge inn sikkerhetsfeil, fikse feil eller legge til nye funksjoner, er vanligvis en god ting for applikasjoner vi bruker hver dag, og vi tenker ikke to ganger på å bruke dem. Men oppdateringer til kjerneinfrastrukturer kan også være skumle når de introduserer ødelagte endringer eller uventet oppførsel for avhengige applikasjoner, eller i andre tilfeller når du ikke oppdaterer i tide kan forårsake brudd. Dette problemet berører små og store enheter, og blockchain er intet unntak.

Hos Alchemy tilbyr vi pålitelig, skalerbar og rask Ethereum-infrastruktur-som-en-tjeneste for kundene våre, slik at de ikke trenger å slite med å opprettholde noder og kan fokusere på å bygge applikasjonene sine. I løpet av vårt arbeid har vi lært mange leksjoner (noen ganger den harde måten!) Om hvordan vi best kan håndtere nettverksgaffler og klientoppdateringer. Med den kommende Constantinoples harde gaffel, trodde vi at dette ville være en fin mulighet til å dele noen av våre beste fremgangsmåter.

Dette er det første av mange blogginnlegg som vi skal skrive om å kjøre Ethereum-infrastruktur på en pålitelig, performant og skalerbar måte.

Konstantinopel

Konstantinopel er Ethereums neste systemomfattende oppgradering og vil implementere fem EIP-er, som faktisk er en del av et større veikart mot Ethereum 2.0. Det er mange innlegg der ute som diskuterer de spesifikke endringene, men det viktigste å merke seg er at ettersom dette er en ikke-omstridt hard gaffel, vil samfunnet ta i bruk den nye gaffelen, noe som gjør tegn og annen stat på ikke-oppdaterte noder verdiløse.

Hvordan påvirker dette deg?

For dapp-utviklere er den viktigste takeaway at du trenger å oppdatere noden din til en Konstantinopel-kompatibel versjon, eller den vil være uforenlig med resten av nettverket forbi blokk 7.080.000. Ethereum-klienter vil mest sannsynlig være oppdatert på harde gafler til kjeden og gi ut en stabil, kompatibel versjon av klienten i god tid før estimert gaffeldato, f.eks. geth og paritet. Hvis du administrerer din egen Ethereum-klientnode, må du oppdatere ethereum-klienten til en versjon som er kompatibel med hardgaffelen. paritet ville være 2.1.10-stabil eller høyere, og geth ville være 1.8.20 eller høyere.

Oppdateringer med hard gaffel skal være få og langt imellom, men Ethereum-klientoppdateringer kan være mye mer vanlig. Hvis du kjører en tjeneste avhengig av kjeden, kan det være gunstig å holde klienten oppdatert for å fikse sikkerhetsfeil eller utnytte ny funksjonalitet. Du må imidlertid være forsiktig så du ikke introduserer uventede problemer i søknaden din.

Beste praksis

Hvis du kjører en tjeneste som krever regelmessig samhandling med Ethereum blockchain, vil et par viktigste fremgangsmåter redde deg fra potensielle katastrofale feil når du oppdaterer nodene dine. Vi vil gå over noen virkelige scenarier med oppdateringer som har gått dårlig, noe som var drivkraften for dette blogginnlegget.

Kjører flere noder

Vi anbefaler på det sterkeste å kjøre flere noder som en generell beste praksis for å opprettholde egen Ethereum-infrastruktur på grunn av de mange fordelene, inkludert økt pålitelighet og skalerbarhet. Imidlertid kan dette introdusere problemer med konsistens og identitet i systemet ditt, som vi vil takle i et påfølgende blogginnlegg.

Når det gjelder oppdateringer gir kjøring av flere noder noen ekstra fordeler:

  1. Ekstra noder fungerer som sikkerhetskopi i tilfelle en oppdatering går galt og gjør en node uopprettelig
  2. Høy tilgjengelighet og ingen driftsstans mens du oppdaterer noder rullende
  3. Tillater regresjonstesting som sammenligner oppdaterte noder med originale noder for å sikre forventet oppførsel

I scenariet med en ikke gjenvinnbar node, kan en ny full arkivknute ta opptil to uker å fullstendig synkronisere. Uten sikkerhetskopi er dette en uakseptabel mengde nedetid.

Eksempel 1: Buggy DB Migration

Et problem vi så når vi oppgraderte paritet fra 1.X.X til 2.X.X var korrupsjon i databasen. Oppdateringen inkluderte en intern DB-migrering som feil konverterte blokknumre i blomsterfilteret, noe som resulterte i tomme resultater for getLog-forespørsler om historiske blokker. Tapet av data var irreversibelt, slik at noden ikke kunne reddes. Vi var heldige nok til å fange det gjennom intern testing på en kanarisk knutepunkt, tilbakevending til våre ikke-oppdaterte noder for å holde systemene våre oppe, og vente til problemet ble løst av paritetsteamet i 2.2.3-beta.

Strengt regresjonstesting

Strenge tester anbefales alltid sterkt for endringer i systemet ditt. På den måten, når du oppdaterer nodene dine, vil du teste for å sikre at applikasjonen og infrastrukturen din fortsetter å fungere som forventet. Å gjøre noe annet kan potensielt utsette brukerne dine og systemene dine for strømbrudd. Med flere løpende noder er den beste måten å garantere dette for å teste de tidligere stabile noder mot en oppdatert kanarisk node. Hvis det oppdages noen ødelagte endringer, må du forsikre deg om at systemene dine trygt kan håndtere dem før du oppdaterer resten av klyngen.

Når det gjelder regresjonstestene, går vi rett til kilden ved å spille om produksjonsforespørsler mot nodene våre. Dette kan gjøres manuelt for en gangs kontroller, men fordi vi støtter så mange prosjekter, har vi bygget et omfattende automatisert testrammeverk som prøver nylige liveforespørsler, erstatter dem på forskjellige klientversjoner og sammenligner resultatene. Dette lar oss bekrefte at koden vår trygt kan samhandle med oppdaterte noder før vi sender til produksjon. Dette rammeverket kan også benyttes for regresjonstester på interne kodeendringer.

Eksempel 2: Endring av formatets responsutgang

Dette var et interessant problem vi kom over da en nyoppdatert klient ga et annet svar på en EVM-utførelsesfeil. Parity 1.11.1-beta returnerte et svar som så ut slik:

{"Jsonrpc": "2.0", "error": {"code": - 32015, "melding": "VM-utførelsesfeil.", "Data": "Returnert 0x"}, "id": 1}

I stedet for svar fra tidligere versjoner som så slik ut:

{ “Jsonrpc”:”2.0" ,” id”: 1,” resultat”:” 0x”}

Endringen av svarformatet er faktisk fordelaktig ettersom det bobler flere utførelsesdetaljer for den som ringer i stedet for lydløst å mislykkes, men kan forårsake problemer hvis koden ikke ble konfigurert for å håndtere den. I dette scenariet fikk sammenligningen av svarutgang endringene, og vi oppdaterte bare systemene våre og advarte kundene våre slik at de ikke ble skremt av den nye responsen, og kunne oppdatere tjenestene deres for å være kompatible.

Bygge på!

Vi håper at dette har vært nyttig, og at disse beste praksisene vil gjøre nodeoppdateringer smertefrie for deg i fremtiden. De har hjulpet oss med å sikre at oppdateringer alltid går greit både for våre egne systemer og for kundene som er avhengige av oss. Vi vet hvor vanskelige vanskelighetene ved å vedlikeholde og skalere noder kan være, og vi ønsker å spre lærdommene vi har hatt gjennom årene.

Hvis du jobber med et Ethereum-prosjekt og ikke ønsker å takle overhead for å opprettholde noder, snakk med oss! Alchemy gir den raskeste, mest skalerbare og mest pålitelige Ethereum-infrastrukturen som en tjeneste, slik at du kan fokusere på å bygge ditt produkt. Under panseret har Alchemy bygget revolusjonerende ny infrastruktur som allerede styrker topp blockchain-prosjekter som Augur, topp blockchain-selskaper som CryptoKitties og topp hedgefond (som forvalter mer enn $ 3 milliarder dollar). Finn ut mer på alchemyapi.io.