Eth2 dev fortæller om udfordringer og erfaringer inden mainnet-lanceringen

Efter år med forsinkelser og ændringer i planer nærmer Ethereum 2.0 sig endelig frigivelse den 1. december.

Ethereum 2.0 fase 0 introducerer den længe ventede mekanisme til staking til den smarte kontraktplatform, ud over at lancere skelettet til en fremtidig Eth2 blockchain, Beacon Chain.

Fremskridt i 2020 steg stadigt, da flere og flere testnet blev introduceret og gentaget. Mens de sammen lykkedes, var de ikke fritaget for problemer relateret til synkronisering og blokproduktion.

En del af disse problemer kom fra udfordringen med at holde det samme tempo mellem syv forskellige klienter eller Ethereum 2.0 node-software, der arbejder med forskellige programmeringssprog og teknologiestakke.

Cointelegraph talte med Zahary Karadjov, forskningsudvikler hos Nimbus – en af ​​disse klienter – for at lære mere om både vejen Ethereum 2.0 har rejst hidtil og de næste ben på rejsen.

Interviewet er let redigeret for længde og kontekst.

Cointelegraph: Nimbus ser ud til at have haft et par flere problemer, der indhenter de delte Ethereum 2.0-specifikationer. Hvorfor tror du det er??

Zahary Karadjov: Vi havde meget travlt med at forberede Nimbus til mainnet. Det er rimeligt at sige, at det har været lidt mere udfordrende for os, fordi det tog os et stykke tid at udvikle nogle af de komponenter, som de andre hold allerede havde til rådighed – mere specifikt Libp2p-netværkslaget.

Dette var noget, vi måtte bygge fra bunden, og det tog os ret lang tid at stabilisere det. Der var et par måneder, hvor vi kæmpede med præstation. Det var først for nylig, at vi offentliggjorde vores oprindelige stabile udgivelse. Men lige nu føler vi os sikre på mainnet: Vi arbejder på det sidste af de små spørgsmål, og vores revision er også afsluttet.

CT: Prysm og Lighthouse – der svarer til eksisterende Ethereum 1.0-klienter blev bygget i henholdsvis Go og Rust – synes at have været foran de andre hidtil. Er det fordi de var i stand til at bygge videre på det arbejde, der blev udført for Ethereum 1.0?

ZK: Min forklaring vil være en forenkling, da der er mange faktorer involveret. Men jeg vil sige, at udvikling af Libp2p har været den mest betydningsfulde kilde til forsinkelser for os. Og logikken er let at se her: Teku, der er udviklet i Java, havde heller ikke en Libp2p-implementering, og den blev også klar på et lidt senere tidspunkt.

Prysm-teamet havde den luksus at have Libp2p udviklet for meget længe siden, da det oprindeligt blev udviklet i Go, mens Lighthouse var i stand til at drage fordel af den implementering, der igen blev skabt for ganske lang tid siden af ​​Parity-teamet for sit arbejde med Polka prik.

Libp2p er netværkslaget af Ethereum 2.0 – du kan sige, at det er en helt anden teknologi end den, der bruges i Ethereum 1.0. I meget praktiske vendinger er det en public-subscribe-teknologi kaldet Gossipsub, som er en optimeret måde at sende information i netværket.

CT: Lad os tale om Medalla testnet. Hvilke lektioner lærte Nimbus og Eth2-samfundet, især i betragtning af de perioder, hvor blockchain ikke leverede blok-final-garantier?

ZK: Nå, kampene med finalitet startede med et teknisk problem. Der er den berømte Cloudflare Roughtime-hændelse, som viste nøjagtigt, hvad vi diskuterede i vores tidligere samtale. Hvis alle på netværket bruger den samme klient, kan et teknisk problem i denne bestemte klient sætte mange validatorer offline, hvilket straks kan gøre netværket til en ikke-afsluttende tilstand.

Vi havde dette problem med Prysm-klienten, og det lærte også en vigtig lektion i vigtigheden af ​​kommunikation. Prysm-teamet var i stand til at give en løsning på dette problem på meget kort tid – bare et par timer. Men det tog et stykke tid for samfundet at indse, at der var et problem, og at implementere rettelsen.

Dette var den første hændelse, der skabte en lang periode med ikke-finalisering for Medalla. Men dette var faktisk meget nyttigt for klienterne, for når netværket ikke er færdigbehandlet, skal klienterne overveje mange forskellige mulige gafler og alternative historier, og dette lægger en masse stress på klienterne. Disse lange perioder med ikke-finalisering tillod os at se og optimere klienterne til disse stressende øjeblikke i netværket, hvor alt ikke kører som forventet.

CT: Under testnet og ikke-finalitetsperioden klagede nogle brugere over, at deres indsats blev reduceret, selvom de var online. Er det en fejl eller en funktion af systemet?

ZK: Du kan beskrive det som en uventet konsekvens. Grundlæggende er problemet, at klienten bliver belønnet for de attester, der sendes på netværket. Men disse attester antages at være inkluderet i blokke. Hvis der ikke er nogen, der producerer blokke, ender dine attester ikke i kæden. Så det ser ud til, at du ikke er aktiv.

Jeg synes, dette problem er anerkendt og anerkendt af implementeringsteamet og forskergruppen. Det skal behandles i fremtiden for Ethereum – i fase 1 eller endda fase 0.5, en af ​​de allerførste opgraderinger af netværket. Men vi bør ikke glemme, at det ville være ret uventet, hvis vi ser lave deltagelsesgrader på mainnet, som når der er en reel indsats involveret, er incitamenterne for validatorer til at være online meget stærkere.

CT: Tror du, at disse kompleksiteter og kravet om konstant at være online kan afvise folk fra at satse med deres egne enheder?

ZK: Nå, dette er en meget almindelig misforståelse om, at jeg synes, vi skal gøre et meget bedre stykke arbejde med at kommunikere. Faktisk er risikoen for ikke at være online hele tiden ikke så stor. Du vil tjene penge, hvis du er online mere end 50% af tiden. Tænk over det: Du kan være offline i halvdelen af ​​året, og du er stadig på nul. Du tjener ikke penge, men du mister heller ikke penge. Protokollen er ret tilgivende i denne henseende.

CT: Hvad kommer efter mainnet-lanceringen af ​​fase 0? Skær den næste opgradering på listen, eller forventer du mere arbejde, der kræves til denne indledende Beacon Chain?

ZK: Der vil helt sikkert være opgraderinger, der kommer med integrationen af ​​fase 1, og det ville kræve brud på ændringer – eller lad os bare kalde det en hård gaffel – hvor klientteamene frigiver ny software, når mere funktionalitet bringes online. Vi forventer udrulning af finalitetsgadget på et eller andet tidspunkt, som vil færdiggøre Ethereum 1.0-kæden gennem konsensusmekanismen i Ethereum 2.0. Alle disse løbende udgivelser vil ske parallelt. De er lidt uafhængige af hinanden og er en del af Ethereum-køreplanen i de næste par år.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map