BlockBeats News, 8 травня охоронна компанія SlowMist випустила нагадування про потенційні нові ризики, пов'язані з новими функціями після оновлення Ethereum Pectra: Для користувачів. Захист приватних ключів завжди має бути головним пріоритетом, майте на увазі, що одна й та сама адреса контракту в різних мережах не завжди може мати однаковий код контракту, і зрозумійте деталі мети делегування, перш ніж продовжити; Для постачальників гаманців. Перевірте, чи делегований ланцюг збігається з поточною мережею, і попередьте користувачів про ризики, пов'язані з використанням делегованого підпису з ідентифікатором ланцюга 0, який може бути повторно відтворений в іншому ланцюжку. Цільовий контракт відображається, коли користувач підписує делегування, щоб знизити ризик фішингових атак. Для розробників. Переконайтеся, що перевірки дозволів виконуються під час ініціалізації гаманця (наприклад, перевірка адреси підпису через ecrecover), дотримуючись формули простору імен, запропонованої в ERC-7201 для пом'якшення конфліктів зберігання; Не думайте, що tx.origin завжди є обліковим записом, що належить external (EOA), використання msg.sender == tx.origin як засобу захисту від атак повторного входу більше не буде ефективним; Переконайтеся, що цільовий контракт, делегований користувачем, реалізує необхідну функцію зворотного виклику для забезпечення сумісності з основними токенами. Для централізованих бірж. Подальші перевірки депозитів, щоб зменшити ризик фальшивих депозитів зі смарт-контрактів.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Компанія Slow Mist опублікувала безпекове попередження про потенційні нові ризики після оновлення Pectra в Ethereum.
BlockBeats News, 8 травня охоронна компанія SlowMist випустила нагадування про потенційні нові ризики, пов'язані з новими функціями після оновлення Ethereum Pectra: Для користувачів. Захист приватних ключів завжди має бути головним пріоритетом, майте на увазі, що одна й та сама адреса контракту в різних мережах не завжди може мати однаковий код контракту, і зрозумійте деталі мети делегування, перш ніж продовжити; Для постачальників гаманців. Перевірте, чи делегований ланцюг збігається з поточною мережею, і попередьте користувачів про ризики, пов'язані з використанням делегованого підпису з ідентифікатором ланцюга 0, який може бути повторно відтворений в іншому ланцюжку. Цільовий контракт відображається, коли користувач підписує делегування, щоб знизити ризик фішингових атак. Для розробників. Переконайтеся, що перевірки дозволів виконуються під час ініціалізації гаманця (наприклад, перевірка адреси підпису через ecrecover), дотримуючись формули простору імен, запропонованої в ERC-7201 для пом'якшення конфліктів зберігання; Не думайте, що tx.origin завжди є обліковим записом, що належить external (EOA), використання msg.sender == tx.origin як засобу захисту від атак повторного входу більше не буде ефективним; Переконайтеся, що цільовий контракт, делегований користувачем, реалізує необхідну функцію зворотного виклику для забезпечення сумісності з основними токенами. Для централізованих бірж. Подальші перевірки депозитів, щоб зменшити ризик фальшивих депозитів зі смарт-контрактів.