Ethereum merge testnet Kintsugi împărțit după erori, iată de ce

Evenimentul de fuziune pe rețeaua Ethereum este tranziția la modelul de consens Proof-of-Stake de la modelul Proof-of-Work utilizat în prezent. Această fuziune înseamnă că actualul sistem de rețea principală Ethereum și noul lanț Beacon, adesea denumit Ethereum 2.0, se vor fuziona într-un singur blockchain.

Pentru a testa fuziunea, rețeaua de testare Kintsugi a fost implementată în decembrie. Scopul rețelei de testare este de a rula diferite cazuri de margine și de a observa modul în care se comportă sistemul. Unul dintre dezvoltatorii implicați în rularea testelor pe Kintsugi este Marius van der Wijden, dezvoltator de bază Ethereum care lucrează cu echipa de clienți Geth (Go-Ethereum).

„Rețeaua de testare a funcționat fără probleme timp de câteva săptămâni. Săptămâna trecută am creat un fuzzer care ar trimite blocuri invalide. Un bloc conține o mulțime de informații, cum ar fi tranzacțiile, hash-ul blocului anterior, limita de gaz etc.”, spune Marius van der Wijden.

Unele implementări nu au executat și nu au verificat blocul

Un fuzzer este un tip comun de instrument de testare folosit în rândul dezvoltatorilor pentru a genera intrări aleatorii pentru funcții sau alte bucăți de cod și pentru a încerca să le facă să se spargă într-un fel sau altul. Este vorba despre a genera intrări neformate și neașteptate și de a urmări ce se întâmplă cu sistemul.

Fuzzer-ul creat de van der Wijden produce un bloc valid și modifică un element al acestuia pentru a-l face invalid. O tehnică pe care o folosește este schimbarea unui element cu altul. În acest caz, fuzzer-ul a schimbat blockhash-ul în hash-ul părinte.

„Nodurile ar trebui să respingă un astfel de bloc modificat. Cu toate acestea, deoarece hash-ul părinte a indicat un bloc valid în sine, unele implementări nu au executat și verificat blocul, ci l-au căutat într-un cache. Deoarece blocul anterior era valid și în cache, ei au presupus că noul bloc este și el valid”, explică van der Wijden.

Rețeaua împărțită de două ori

Rezultatul a fost că jumătate din rețea, clienții Geth, au respins blocul, în timp ce cealaltă jumătate, clienții Nethermind și Besu, l-au acceptat, provocând despărțirea lanțului, deoarece acum aveam două vederi diferite asupra stării corecte. Pentru a înrăutăți lucrurile, mai era o problemă pe deasupra.

Potrivit lui van der Wijden, nodurile lanțului Geth, la rândul lor, care constă din Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth și Teku-Geth, s-au împărțit de asemenea între ele.

„Această divizare este încă investigată, dar se pare că Teku ar putea avea și un mecanism de stocare în cache care a eșuat”, spune van der Wijden.

Deoarece în momentul scrierii există mai multe furci diferite ale rețelei de testare Kintsugi și fiecare nod crede că se află pe o furcă corectă, rețeaua nu se mai finalizează.

„Vom găsi ceva pentru a restabili rețeaua. Am actualizat deja clientul Nethermind și acele noduri sunt acum pe lanțul corect. Încă avem nevoie de remedierea Teku, deoarece mai mult de 33% dintre noduri sunt Teku, altfel lanțul nu se va finaliza”, spune van der Wijden.

Incidentul aduce ceva bun

Potrivit lui van der Wijden, acest incident nu interzice sau întârzie testarea ulterioară a fuziunii Ethereum și nici nu întârzie fuziunea în sine. De fapt, van der Wijden spune că incidentul ajută de fapt la testarea cazurilor marginale care ar fi fost dificil de testat dacă rețeaua funcționa corect.

„Perioadele lungi de nefinalizare sunt o provocare pentru noduri și este foarte important pentru noi să vedem cum se comportă în acest moment. Credem că testnet-ul se va reîntoarce în cele din urmă, dar nu cred că vom încerca să-l reparăm manual, deoarece ne oferă posibilitatea de a testa cazuri de margine interesante.”

„Nu cred că acest lucru va întârzia fuziunea, deoarece fuziunea nu este încă programată. Dar arată cât de importantă este testarea. Cred că fuziunea progresează foarte bine. Avem nevoie de încă câteva săptămâni pentru a pune software-ul într-o stare acceptabilă, apoi avem nevoie de câteva luni pentru a-l testa”, spune van der Wijden.

Ce se întâmplă dacă acest lucru se întâmplă pe rețeaua principală?

O întrebare interesantă este ce s-ar fi întâmplat dacă ar fi apărut o eroare ca aceasta pe mainchain.

„Am început testarea destul de devreme, așa că ne așteptam la câteva erori de genul acesta. O astfel de eroare pe rețeaua principală ar fi totuși destul de urâtă, deoarece ar trebui să găsim și să remediam eroarea, la care suntem destul de buni, să eliberăm codul și apoi să le anunțăm tuturor participanților că ar trebui să-și actualizeze nodurile. Ultima parte este partea grea în opinia mea, deoarece unii utilizatori nu urmăresc dezvoltarea prea îndeaproape”, spune van der Wijden.

Pentru mai multe detalii, cititorul interesat este încurajat să citească pe cel al lui Marius van der Wijden tweets asupra incidentului.