Последний раунд разработки тестовой сети Ethereum Shapella выявил несколько ошибок

Тестирование в тестовой сети Ethereum Zhejiang перед обновлением Shanghai-Capella выявило некоторые ошибки, но ничего, что повлияет на сроки введения ставок в сети. 

Разработчик Мариус ВанДерВийден документированный ошибка синхронизации, с которой столкнулись другие клиенты, и разработчики уверены, что ее можно исправить, согласно ветке Тима Бейко из Ethereum Foundation. Он отметил, что ошибка не повлияет на какие-либо установленные сроки для предлагаемого набора обновлений для тестовой сети Sepolia, запланированного на 28 февраля.

В последнем обновлении devnet для вывода подробно описан стресс-тест, состоящий из 600,000 360,000 валидаторов, XNUMX XNUMX из которых выполняли обновления учетных данных вывода во время форка. По словам Бейко, произошли всплески клиентских ОЗУ и ЦП, и разработчики будут оценивать количество потерянных и записанных сообщений об обновлении учетных данных в ближайшие дни.

Стресс-тест также выявил ошибку между клиентом Proof-of-Stake, Prysm, и клиентом Besu, который предназначен для разрешенных вариантов использования. Для правильной синхронизации клиент Prysm ожидает определенное количество ответов; однако Besu накладывает ограничения на отклик, из-за которых он становится ниже необходимого порога синхронизации, сказал Бейко. Команда Бесу изучает этот вопрос.

Бан без блоба

После обсуждения того, как лучше всего оптимизировать первоначальную ориентацию на клиента, разработчики в конечном итоге решенный полностью запретить транзакции 4844 без больших двоичных объектов, что изменит предположения клиентов о транзакциях и может усложнить настройку.

Разработчики также обсудили, как продвигаться вперед с отказом от использования ключевого слова SELFDESTRUCT, которое расторгает контракт, удаляет байт-код контракта из блокчейна и перенаправляет средства по контакту на указанный адрес.

Хотя путь вперед остается неясным, в настоящее время обсуждаются три предложения по этому вопросу, поскольку разработчики стремятся найти «параметры деактивации, которые не нарушают работу», — сказал Бейко.

«Проблема здесь в том, что это открывает неприятный вектор атаки: разверните контракт, заполните хранилище определенным образом, и когда вы повторно развернете контракт, старое хранилище все еще будет там, и к нему можно будет получить доступ злоумышленниками», — сказал Бейко.