De laatste ronde van de ontwikkeling van het Ethereum Shapella-testnet onthult een paar bugs

Testen op het Zhejiang-testnet van Ethereum voorafgaand aan de Shanghai-Capella-update bracht enkele bugs aan het licht, maar niets dat de tijdlijn voor de introductie van staking op het netwerk zal beïnvloeden. 

Ontwikkelaar Marius VanDerWijden gedocumenteerd een synchronisatiefout die is tegengekomen door andere klanten waarvan ontwikkelaars zeker weten dat deze kan worden gepatcht, volgens een thread van Tim Beiko van de Ethereum Foundation. De bug heeft geen invloed op vastgestelde tijdlijnen voor de voorgestelde upgradeset voor het Sepolia-testnet dat gepland staat voor 28 februari, merkte hij op.

De laatste update van het opname-devnet beschrijft een stresstest bestaande uit 600,000 validators, van wie er 360,000 opnamereferenties hebben bijgewerkt op het moment van de splitsing. Client-pieken in RAM en CPU deden zich voor en ontwikkelaars zullen de komende dagen het aantal verloren versus geregistreerde referentie-updateberichten meten, zei Beiko.

De stresstest bracht ook een bug aan het licht tussen een proof-of-stake-client, Prysm, en de Besu-client die is ontworpen voor toegestane use-cases. Om correct te kunnen synchroniseren, verwacht de Prysm-client een bepaald aantal reacties; Besu legt echter responsbeperkingen op die het onder de noodzakelijke synchronisatiedrempel brengen, zei Beiko. Het Besu-team onderzoekt de zaak.

Blobless verbod

Na een discussie over hoe de initiële klantoriëntatie het beste kan worden geoptimaliseerd, komen uiteindelijk ontwikkelaars beslist om blobless 4844-transacties volledig te verbieden, wat de aannames van klanten rond de transacties zou veranderen en de installatie zou kunnen bemoeilijken.

Ontwikkelaars bespraken ook hoe verder te gaan met de afschaffing van het SELFDESTRUCT-sleutelwoord, dat een contract beëindigt, de bytecode van het contract uit de blockchain verwijdert en geld op het contact omleidt naar een opgegeven adres.

Hoewel de weg voorwaarts onduidelijk blijft, zijn er momenteel drie voorstellen over dit onderwerp in discussie, terwijl ontwikkelaars proberen "deactiverende opties te vinden die de dingen niet kapot maken", zei Beiko.

"De uitdaging hier is dat het een vervelende aanvalsvector opent: implementeer een contract, vul opslag op een bepaalde manier, en wanneer je het contract opnieuw implementeert, is de oude opslag er nog steeds en kan er op kwaadaardige manieren toegang toe worden verkregen", zei Beiko.