" Испытания в тестовой сети Ethereum Zhejiang перед обновлением Shanghai-Capella выявили некоторые ошибки, но ни одна из них не повлияет на сроки предстоящего обновления.
Разработчик Marius VanDerWijden задокументировал ошибку синхронизации, с которой столкнулись другие клиенты, и разработчики уверены, что ее можно исправить, согласно ветке Тима Бейко из Ethereum Foundation. Он отметил, что ошибка не повлияет на какие-либо установленные сроки для предлагаемого набора обновлений для тестовой сети Sepolia, запланированного на 28 февраля.
В последнем обновлении devnet для вывода подробно описан стресс-тест, состоящий из 600 000 валидаторов, 360 000 из которых выполняли обновления учетных данных вывода во время форка. По словам Бейко, произошли всплески использования клиентских ОЗУ и ЦП, и разработчики будут оценивать количество потерянных и записанных сообщений об обновлении учетных данных в ближайшие дни.
Стресс-тест также выявил ошибку между клиентом Proof-of-Stake, Prysm, и клиентом Besu, который предназначен для разрешенных вариантов использования. Для правильной синхронизации клиент Prysm ожидает определенное количество ответов; однако Besu накладывает ограничения на отклик, из-за которых он становится ниже необходимого порога синхронизации, сказал Бейко. Команда Besu изучает этот вопрос.
Безопасный бан
После обсуждения того, как лучше всего оптимизировать первоначальную ориентацию на клиента, разработчики в конечном итоге решили полностью запретить транзакции 4844 без больших двоичных объектов, что изменит предположения клиентов о транзакциях и может усложнить настройку.
Разработчики также обсудили, как продвигаться вперед с отказом от использования ключевого слова SELFDESTRUCT, которое расторгает контракт, удаляет байт-код контракта из блокчейна и перенаправляет средства по контакту на указанный адрес.
Хотя решение остается неясным, в настоящее время обсуждаются три предложения по этому вопросу, поскольку разработчики стремятся найти «параметры деактивации, которые не нарушают работу», — сказал Бейко.
«Проблема здесь в том, что это открывает неприятный вектор атаки: разверните контракт, заполните хранилище определенным образом, и когда вы повторно развернете контракт, старое хранилище все еще будет там, и к нему можно будет получить доступ злоумышленниками», — сказал Бейко.
