Ultima rundă de dezvoltare a testnetului Ethereum Shapella dezvăluie câteva erori

Testarea pe rețeaua de testare Zhejiang a Ethereum înaintea actualizării Shanghai-Capella a dezvăluit unele erori, dar nimic care să afecteze cronologia pentru introducerea staking-ului în rețea. 

Dezvoltatorul Marius VanDerWijden documentat o eroare de sincronizare întâlnită de alți clienți despre care dezvoltatorii sunt siguri că poate fi remediată, potrivit unui thread de la Tim Beiko de la Fundația Ethereum. Bug-ul nu va afecta niciun termen stabilit pentru setul de upgrade propus pentru testnetul Sepolia programat pentru 28 februarie, a menționat el.

Cea mai recentă actualizare devnet de retragere a detaliat un test de stres constând din 600,000 de validatori, dintre care 360,000 au efectuat actualizări de acreditări de retragere în momentul furcării. Au avut loc creșteri ale clienților în RAM și CPU, iar dezvoltatorii vor evalua numărul de mesaje de actualizare a acreditărilor pierdute față de cele înregistrate în zilele următoare, a spus Beiko.

Testul de stres a dezvăluit, de asemenea, o eroare între un client proof-of-stake, Prysm, și clientul Besu, care este proiectat pentru cazuri de utilizare permise. Pentru a sincroniza corect, clientul Prysm așteaptă un anumit număr de răspunsuri; cu toate acestea, Besu impune limitări de răspuns care îl aduc sub pragul necesar de sincronizare, a spus Beiko. Echipa Besu analizează chestiunea.

Blobless interdicție

După o discuție despre cum să optimizați cel mai bine orientarea inițială către client, dezvoltatorii în cele din urmă hotărât pentru a interzice complet tranzacțiile blobless 4844, ceea ce ar schimba ipotezele clienților cu privire la tranzacții și ar putea complica configurarea.

Dezvoltatorii au discutat, de asemenea, cum să mergem mai departe cu deprecierea cuvântului cheie SELFDESTRUCT, care reziliază un contract, elimină bytecode-ul contractului din blockchain și redirecționează fondurile de pe contact către o adresă specificată.

Deși calea de urmat rămâne neclară, există trei propuneri curente pe acest subiect în discuție, deoarece dezvoltatorii caută să găsească „opțiuni de dezactivare care să nu distrugă lucrurile”, a spus Beiko.

„Provocarea aici este că deschide un vector de atac neplăcut: implementați un contract, umpleți spațiul de stocare într-un anumit mod, iar când redistribuiți contractul, stocarea veche este încă acolo și poate fi accesată în moduri rău intenționate”, a spus Beiko.