Pēc gadiem ilgas kavēšanās un izmaiņām plānos Ethereum 2.0 beidzot tuvojas izlaišanai 1. decembrī.
Ethereum 2.0 Phase 0 ievieš ilgi gaidīto piesaistes mehānismu viedo līgumu platformā, kā arī nākamā Eth2 blokķēdes skeleta palaišanu, Beacon Chain.
Progress 2020. gadā vienmērīgi paātrināja tempu, jo tika ieviesti un atkārtoti veikti vairāk un vairāk testnetu. Lai gan kopumā tie bija veiksmīgi, viņi netika atbrīvoti no problēmām, kas saistītas ar sinhronizāciju un bloķēšanu.
Daļa no šiem jautājumiem radās ar uzdevumu saglabāt vienādu tempu starp septiņiem dažādiem klientiem vai mezglu programmatūru Ethereum 2.0, strādājot ar dažādām programmēšanas valodām un tehnoloģiju kaudzēm.
Cointelegraph runāja ar Nimbus pētījumu izstrādātāju Zahariju Karadjovu – vienu no šiem klientiem -, lai uzzinātu vairāk gan par Ethereum 2.0 līdz šim nobraukto ceļu, gan nākamajiem ceļa posmiem.
Intervija ir viegli rediģēta pēc garuma un konteksta.
Cointelegraph: Šķiet, ka Nimbus ir bijuši vēl daži jautājumi, panākot koplietotās Ethereum 2.0 specifikācijas. Kāpēc jūs domājat, ka tā ir?
Zaharijs Karadjovs: Mēs bijām ļoti aizņemti, gatavojot Nimbus mainnet. Ir taisnīgi teikt, ka mums tas ir bijis nedaudz sarežģītāk, jo mums vajadzēja kādu laiku, lai izstrādātu dažus komponentus, kas jau bija pieejami citām komandām – precīzāk, Libp2p tīkla slānis.
Tas bija kaut kas, kas mums bija jāveido no nulles, un mums vajadzēja diezgan daudz laika, lai to stabilizētu. Bija daži mēneši, kad mēs cīnījāmies ar sniegumu. Tikai nesen mēs publicējām savu sākotnējo stabilo laidienu. Bet šobrīd mēs jūtamies pārliecināti par mainnet: mēs strādājam pie pēdējiem mazajiem jautājumiem, un arī mūsu revīzija ir pabeigta.
CT: Prysm un Lighthouse – kas līdzīgi esošajiem Ethereum 1.0 klientiem tika uzbūvēti attiecīgi Go un Rust -, šķiet, līdz šim ir bijuši priekšā citiem. Vai tas ir tāpēc, ka viņi varēja izmantot Ethereum 1.0 veikto darbu?
ZK: Mans skaidrojums būs vienkāršojums, jo tajā ir daudz faktoru. Bet es teiktu, ka Libp2p izstrāde mums ir bijis nozīmīgākais kavēšanās avots. Un loģika ir viegli saskatāma šeit: Teku, kas izstrādāts Java, arī nebija Libp2p ieviešanas, un tas arī bija gatavs nedaudz vēlāk.
Prysm komandai bija greznība, ka Libp2p tika izstrādāta ļoti sen, jo tā sākotnēji tika izstrādāta Go, savukārt Lighthouse varēja izmantot ieviešanu, ko atkal pirms kāda laika izveidoja Parity komanda par darbu Punktains.
Libp2p ir Ethereum 2.0 tīkla slānis – jūs varat teikt, ka tā ir pilnīgi atšķirīga tehnoloģija no tās, kas tiek izmantota Ethereum 1.0. Ļoti praktiski tā ir publicēšanas-abonēšanas tehnoloģija ar nosaukumu Gossipsub, kas ir optimizēts veids, kā pārraidīt informāciju tīklā.
CT: Parunāsim par Medalla testnet. Kādas mācības apguva Nimbus un Eth2 kopiena, īpaši ņemot vērā periodus, kad blokķēde nesniedza bloku galīguma garantijas?
ZK: Nu, cīņa ar galīgumu sākās ar tehnisku problēmu. Ir slavenais Cloudflare Roughtime incidents, kas parādīja tieši to, ko mēs apspriedām iepriekšējā sarunā. Ja visi tīkla lietotāji izmanto vienu un to pašu klientu, šī klienta tehniska problēma var padarīt daudz validatoru bezsaistē, kas nekavējoties var padarīt tīklu par nepabeigtu.
Mums šis jautājums radās ar Prysm klientu, un tas arī sniedza svarīgu mācību par saziņas nozīmi. Prysm komanda spēja nodrošināt problēmas risinājumu ļoti īsā laikā – tikai pāris stundās. Bet pagāja diezgan ilgs laiks, līdz sabiedrība saprata, ka pastāv problēma, un ieviesa labojumu.
Tas bija sākotnējais incidents, kas Medallai radīja ilgu nepabeigšanas periodu. Bet tas patiesībā bija ļoti noderīgs klientiem, jo, kad tīkls vēl nav pabeigts, klientiem ir jāapsver daudz dažādu iespējamo dakšu un alternatīvās vēstures, un tas klientiem rada lielu stresu. Tātad šie ilgie nepabeigšanas periodi ļāva mums redzēt un optimizēt klientus šiem stresa brīžiem tīklā, kur viss nedarbojas, kā paredzēts.
CT: testēšanas laikā un nebeidzamības periodā daži lietotāji sūdzējās, ka viņu daļa ir samazināta pat tad, ja viņi ir tiešsaistē. Vai tā ir kļūda vai sistēmas iezīme?
ZK: Jūs to varētu raksturot kā neparedzētas sekas. Būtībā problēma ir tā, ka klients saņem atlīdzību par tīklā pārraidītajiem apliecinājumiem. Bet šie apliecinājumi ir jāiekļauj blokos. Ja nav neviena, kas ražotu blokus, jūsu apliecinājumi nenonāk ķēdē. Tātad, šķiet, ka jūs neesat aktīvs.
Es domāju, ka īstenošanas komanda un pētnieku grupa ir labi atzinusi un atzinusi šo jautājumu. Tas būtu jārisina Ethereum nākotnē – 1. vai pat 0.5. Posmā, kas ir viens no pirmajiem tīkla jauninājumiem. Bet nevajadzētu aizmirst, ka tas būtu diezgan negaidīti, ja redzētu zemu dalības līmeni mainnet tīklā, jo, ja ir iesaistītas reālas spēles, stimuli validatoriem būt tiešsaistē ir daudz spēcīgāki.
CT: Vai jūs domājat, ka šīs sarežģītības un prasība pastāvīgi uzturēties tiešsaistē var novērst cilvēkus no spēles ar savām ierīcēm?
ZK: Nu, tas ir ļoti izplatīts nepareizs uzskats, ka, manuprāt, mums vajadzētu darīt daudz labāku komunikācijas darbu. Patiesībā riski, ka visu laiku nebūsit tiešsaistē, nav tik lieli. Jūs gūsiet peļņu, ja vairāk nekā 50% gadījumu esat tiešsaistē. Padomājiet par to: pusi gada varat būt bezsaistē, un jūs joprojām būsiet nulle. Jūs nepelnīsit naudu, bet nezaudēsiet arī naudu. Šajā ziņā protokols ir diezgan piedodošs.
CT: Kas notiek pēc 0 fāzes galvenās palaišanas? Sadala nākamo jauninājumu sarakstā vai arī jūs sagaidāt vairāk darba, kas vajadzīgs šai sākotnējai bākas ķēdei?
ZK: Noteikti būs jauninājumi, kas saistīti ar 1. fāzes integrāciju, un tam būtu nepieciešamas pārrāvuma izmaiņas – vai vienkārši sauksim to par cieto dakšiņu – kur klientu komandas izlaidīs jaunu programmatūru, jo tiešsaistē tiek piedāvāta vairāk funkcionalitātes. Mēs sagaidām, ka kādā brīdī tiks ieviests galīgais sīkrīks, kas pabeigs Ethereum 1.0 ķēdi, izmantojot Ethereum 2.0 vienprātības mehānismu. Visi šie notiekošie laidieni notiks paralēli. Viņi ir mazliet neatkarīgi viens no otra un ir daļa no Ethereum ceļveža nākamajiem gadiem.