Останній раунд розробки тестової мережі Ethereum Shapella виявив кілька помилок

Тестування в тестовій мережі Ethereum Zhejiang перед оновленням Shanghai-Capella виявило деякі помилки, але нічого, що вплине на часові рамки впровадження стекінгу в мережу. 

Розробник Marius VanDerWijden документований помилка синхронізації, з якою стикаються інші клієнти, яку розробники впевнені, що можна виправити, згідно з темою Тіма Бейко з Ethereum Foundation. Помилка не вплине на встановлені терміни для запропонованого набору оновлень для тестової мережі Sepolia, запланованого на 28 лютого, зазначив він.

В останньому оновленні Devnet для виведення коштів детально описано стрес-тест, що складається з 600,000 360,000 валідаторів, XNUMX XNUMX з яких оновлювали облікові дані для виведення під час форку. За словами Бейко, відбулися стрибки оперативної пам’яті та процесора клієнта, і розробники оцінять кількість втрачених повідомлень про оновлення облікових даних у порівнянні з записаними протягом найближчих днів.

Стрес-тест також виявив помилку між клієнтом proof-of-stake, Prysm, і клієнтом Besu, який призначений для дозволених випадків використання. Для належної синхронізації клієнт Prysm очікує певної кількості відповідей; однак Besu накладає обмеження на відповідь, які опускають його нижче необхідного порогу синхронізації, сказав Бейко. Команда Besu вивчає це питання.

Заборона без крапель

Після обговорення того, як найкраще оптимізувати початкову орієнтацію на клієнта, розробники зрештою вирішене повністю заборонити транзакції blobless 4844, що змінить припущення клієнта щодо транзакцій і може ускладнити налаштування.

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

Хоча шлях уперед залишається незрозумілим, на даний момент обговорюється три пропозиції, оскільки розробники прагнуть знайти «параметри дезактивації, які не ламають роботу», сказав Бейко.

«Завдання тут полягає в тому, що це відкриває неприємний вектор атаки: розгорніть контракт, заповніть сховище певним чином, і коли ви перерозподілите контракт, старе сховище все ще там, і до нього можна отримати зловмисний доступ», — сказав Бейко.