Die letzte Runde der Entwicklung des Ethereum Shapella-Testnetzes enthüllt einige Fehler

Das Testen auf dem Zhejiang-Testnetz von Ethereum vor dem Shanghai-Capella-Update ergab einige Fehler, aber nichts, was den Zeitplan für die Einführung von Staking im Netzwerk beeinflussen wird. 

Entwickler Marius VanDerWijden dokumentiert Ein Synchronisierungsfehler, auf den andere Clients gestoßen sind und von dem die Entwickler überzeugt sind, dass er gepatcht werden kann, heißt es in einem Thread von Tim Beiko von der Ethereum Foundation. Der Fehler wird keine etablierten Zeitpläne für das vorgeschlagene Upgrade-Set für das Sepolia-Testnetz beeinflussen, das für den 28. Februar geplant ist, bemerkte er.

Das neueste Devnet-Update für Auszahlungen beschrieb einen Stresstest mit 600,000 Validierern, von denen 360,000 zum Zeitpunkt des Forks Aktualisierungen der Auszahlungsberechtigungen durchführten. Client-Spitzen in RAM und CPU traten auf und Entwickler werden in den kommenden Tagen die Anzahl der verlorenen im Vergleich zu den aufgezeichneten Anmeldeinformationen-Aktualisierungsnachrichten messen, sagte Beiko.

Der Stresstest enthüllte auch einen Fehler zwischen einem Proof-of-Stake-Client, Prysm, und dem Besu-Client, der für zugelassene Anwendungsfälle entwickelt wurde. Für eine ordnungsgemäße Synchronisierung erwartet der Prysm-Client eine bestimmte Anzahl von Antworten; Besu erlegt jedoch Reaktionsbeschränkungen auf, die es unter die notwendige Synchronisierungsschwelle bringen, sagte Beiko. Das Besu-Team untersucht die Angelegenheit.

Blobless-Verbot

Nach einer Diskussion darüber, wie die anfängliche Kundenorientierung am besten optimiert werden kann, werden Entwickler schließlich entschieden Blobless 4844-Transaktionen vollständig zu verbieten, was die Client-Annahmen in Bezug auf die Transaktionen ändern und die Einrichtung erschweren könnte.

Die Entwickler diskutierten auch darüber, wie man mit der Abschaffung des Schlüsselworts SELFDESTRUCT vorankommen kann, das einen Vertrag beendet, den Bytecode des Vertrags aus der Blockchain entfernt und Gelder für den Kontakt an eine bestimmte Adresse umleitet.

Während der Weg nach vorne unklar bleibt, gibt es drei aktuelle Vorschläge zu diesem Thema in der Diskussion, da Entwickler versuchen, „Deaktivierungsoptionen zu finden, die nichts kaputt machen“, sagte Beiko.

„Die Herausforderung hier ist, dass es einen bösen Angriffsvektor eröffnet: Stellen Sie einen Vertrag bereit, füllen Sie den Speicher auf eine bestimmte Weise, und wenn Sie den Vertrag erneut bereitstellen, ist der alte Speicher immer noch vorhanden und könnte auf böswillige Weise zugegriffen werden“, sagte Beiko.