*Forward the Original Title：坎昆升级前，项目开发者必看的几项安全检查

TL;DR: З наближенням оновлення Канкун воно включає шість запропонованих EIP-змін, головним чином EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 та EIP-7516. EIP-4844 спрямований на покращення масштабованості Ethereum, зменшення вартості транзакцій та прискорення транзакцій для рішень Layer 2. Оновлення було протестоване на тестових мережах Ethereum і заплановане для активації на головній мережі 13 березня. Salus склав важливі питання безпеки для розробників перевірити перед оновленням.

Огляд пропозицій EIP

Офіційні питання безпеки

Ризики, пов'язані з розумними контрактами

Додаткова література

Огляд пропозицій EIP

EIP-1153

EIP-1153 вводить тимчасові опкоди зберігання, які використовуються для маніпулювання станом таким же чином, як зберігання, але з тимчасовим зберіганням, яке видаляється після кожної транзакції. Це означає, що тимчасове зберігання не десеріалізує значення зберігання, або серіалізує значення до зберігання, що призводить до зниження витрат через уникнення доступу до диска. З введенням двох нових опкодів, TLOAD і TSTORE (де "T" означає "тимчасовий"), розумні контракти можуть отримати доступ до тимчасового зберігання. Ця пропозиція має на меті забезпечити відведене та ефективне рішення для комунікації між кількома вкладеними фреймами виконання під час виконання транзакції в Ethereum.

EIP-4788

EIP-4788 має на меті викрити корені хеш-дерев блоків ланцюга маяка до EVM, що дозволяє отримати доступ до цих коренів у межах смарт-контрактів. Це дозволяє отримати доступ до стану рівня консенсусу без довіри, підтримуючи різноманітні використання, такі як стейкінг-пули, структури повторного стейкінгу, мости смарт-контрактів та мітігація MEV. Пропозиція досягає цього, зберігаючи ці корені в смарт-контракті та використовуючи циклічний буфер для обмеження споживання пам'яті, забезпечуючи, що кожен блок виконання потребує лише постійного простору для представлення цієї інформації.

EIP-4844

EIP-4844 вводить новий формат транзакцій, що називається "Shard Blob Transactions", розроблений для розширення доступності даних Ethereum простим і сумісним з попередніми способами. Ця пропозиція досягає своєї мети, вводячи "транзакції з об'ємами", що містять велику кількість даних, до яких не може отримати доступ EVM, але до яких можна отримати доступ за їхніми зобов'язаннями. Цей формат повністю сумісний з форматом, що використовуватиметься у майбутньому повністю розподіленому шаруванні, надаючи тимчасове, але значне полегшення для масштабованості rollup.

EIP-5656

EIP-5656 представляє нову інструкцію EVM, MCOPY, для ефективного копіювання областей пам'яті. Ця пропозиція має на меті зменшити накладні витрати на операції копіювання пам'яті на EVM шляхом прямого копіювання даних між пам'яттю за допомогою інструкції MCOPY. MCOPY дозволяє перекривати адреси джерела та призначення, розроблені з урахуванням зворотної сумісності, і має на меті підвищити ефективність виконання в різних сценаріях, включаючи побудову структури даних, ефективний доступ та копіювання об'єктів пам'яті.

EIP-6780

EIP-6780 модифікує функціональність опкоду SELFDESTRUCT. У цій пропозиції SELFDESTRUCT лише видаляє рахунки та переказує всі етери у тій же транзакції, що й створення контракту. Крім того, при виконанні SELFDESTRUCT контракт не буде видалено, але передасть всі етери в зазначену ціль. Ця зміна сприяє майбутньому використанню дерев Verkle, спрямованому на спрощення реалізації EVM, зменшення складності змін стану, при цьому зберігаючи деякі загальні випадки використання SELFDESTRUCT.

EIP-7516

EIP-7516 вводить нову інструкцію EVM, BLOBBASEFEE, для повернення базового значення оплати за блоки в поточному виконанні блоку. Ця інструкція схожа на опкод BASEFEE, введений в EIP-3198, з відмінністю у тому, що вона повертає базову оплату за блок, визначену відповідно до EIP-4844. Ця функціональність дозволяє контрактам програмно розглядати ціну газу для даних блоків, дозволяючи контрактам rollup розраховувати витрати на використання даних блоків без довіри або реалізувати ф'ючерси газу для згладжування витрат на дані блоків.

Офіційні врахування безпеки

EIP-1153

Розробники розумних контрактів повинні розуміти життєвий цикл тимчасових змінних зберігання перед їх використанням. Оскільки тимчасове сховище автоматично очищається в кінці транзакції, розробники розумних контрактів можуть спробувати уникнути очищення слотів під час виклику для зекономлення газу. Однак це може запобігти подальшій взаємодії з контрактом в тій же транзакції (наприклад, у випадку рекурсивних блокувань) або призвести до інших помилок. Тому розробники розумних контрактів повинні бути обережними і зберігати лише ненульові значення, коли тимчасовий слот сховища призначений для майбутніх викликів у межах тієї самої транзакції. В іншому випадку поведінка цих опкодів ідентична до SLOAD та SSTORE, тому всі загальні питання безпеки застосовуються, особливо щодо ризиків рекурсивності.

Розробники смарт-контрактів також можуть спробувати використовувати тимчасове сховище як альтернативу картографуванню пам'яті. Вони повинні усвідомлювати, що тимчасове сховище не видаляється, як пам'ять, коли виклик повертається або скасовується, і повинні надавати перевагу пам'яті в таких випадках використання, щоб уникнути непередбачуваної поведінки під час повторного входу в ту саму транзакцію. Висока вартість тимчасового сховища в пам'яті вже повинна віддисциплінувати цей шаблон використання. Більшість випадків використання відображень в пам'яті можуть бути краще реалізовані через відсортований список записів за ключем, і тимчасове сховище в картографуванні пам'яті мало коли потрібне в смарт-контрактах (тобто немає відомих випадків виробництва).

EIP-4844

Цей EIP збільшує вимоги до пропускної здатності для кожного блоку маяка на приблизно 0,75 МБ. Це 40% збільшення порівняно з теоретичним максимальним розміром сьогоднішніх блоків (30M Gas / 16 Gas за байт calldata = 1,875M байт), тому це не суттєво збільшує пропускну здатність у найгірших випадках. Після злиття час блоку є статичним, а не непередбачувано розподіленим за законом Пуассона, забезпечуючи гарантований часовий проміжок для поширення великих блоків.

Навіть з обмеженою кількістю даних виклику постійне навантаження цієї EIP значно нижче, ніж альтернативні рішення, які можуть знизити вартість даних виклику, оскільки для зберігання Blob-даних не потрібно утримувати їх протягом того ж самого часу, що й навантаження на виконання. Це дозволяє втілювати стратегії, які вимагають, щоб ці блоки даних зберігалися принаймні протягом певного часу. Конкретне значення, вибране, - це епоха MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, яка становить приблизно 18 днів, набагато коротше, ніж запропонований (але ще не втілений) однорічний час обертання для виконання дійсних історій корисних навантажень.

EIP-5656

Клієнти повинні мати на увазі, що їх імплементації не використовують проміжні буфери (наприклад, функція C stdlib memmove не використовує проміжні буфери), оскільки це потенційний вектор відмови в обслуговуванні (DoS). Більшість вбудованих функцій мови / функцій стандартної бібліотеки, які використовуються для переміщення байтів, мають правильні характеристики продуктивності тут.

Крім того, аналіз атак відмови в обслуговуванні (DoS) та виснаження пам'яті аналогічний для інших опкодів, які торкаються пам'яті, оскільки розширення пам'яті відбувається за тими ж правилами ціноутворення.

EIP-6780

Наступні застосування SELFDESTRUCT будуть розбиті, і застосування, які використовують його таким чином, більше не є безпечними:

Де використовується CREATE2, щоб перевидати контракт на тій самій позиції для того, щоб контракти можна було оновлювати. Ця функціональність більше не підтримується і повинна бути замінена на ERC-2535 або інші типи проксі-контрактів.

Якщо контракт покладається на знищення ефіру контрактом через SELFDESTRUCT на користь, контракт не створюється в тій самій транзакції.

Ризики, пов'язані з розумним контрактом

EIP1153

Розгляньте два сценарії за допомогою опкодів TLOAD та TSTORE:

1. Використовують ці опкоди у викликаних контрактах.
2. Виклик контрактів використовує ці опкоди.

Ризик 1:

Порівняно з традиційним SSTORE та SLOAD, введення тимчасового сховища в основному змінює тривалість зберігання даних. Дані, збережені за допомогою TSTORE, читаються через TLOAD і будуть видалені після виконання транзакції, а не залишаться назавжди записаними в контракт, як SSTORE. Розробники повинні розуміти характеристики цих опкодів при їх використанні, щоб уникнути неправильного використання, що може призвести до того, що дані не будуть правильно записані в контракті, що може призвести до втрат. Крім того, дані, збережені за допомогою TSTORE, є приватними і можуть бути доступні лише контрактом самим. Якщо потрібен зовнішній доступ до цих даних, їх потрібно передавати через параметри або тимчасово зберігати у відкритій змінній сховища.

Ризик 2:

Ще одним потенційним ризиком є те, що якщо розробники смарт-контрактів не керують життєвим циклом тимчасових змінних сховища правильно, це може призвести до очищення даних у непридатні часи або неправильного збереження. Якщо контракт очікує використання даних, збережених у тимчасовому сховищі, підчас наступних викликів транзакції, але не вдається належним чином керувати життєвим циклом цих даних, це може спричинити помилкову спільництво або втрату даних між різними викликами, що призводить до логічних помилок або уразливостей безпеки. Неправильне збереження даних, таких як баланс або дані про дозвіл у проектах токенів, може призвести до логічних помилок в контрактах, що призводить до втрат. Також, використання цих опкодів для встановлення адреси власника може призвести до того, що привілейована адреса не буде правильно записана, що може призвести до втрати змін до важливих параметрів контракту.

Розглянемо смарт-контракт, який використовує тимчасове зберігання для тимчасового запису ціни транзакції на платформі для торгівлі криптовалютою. Контракт оновлює ціну після кожної транзакції та дозволяє користувачам запитувати останню ціну протягом короткого періоду. Однак, якщо дизайн контракту не враховує автоматичне очищення тимчасового сховища в кінці транзакції, може бути період між закінченням однієї транзакції та початком наступної, коли користувачі можуть отримати неправильну або застарілу ціну. Це може не тільки призвести до того, що користувачі прийматимуть рішення на основі неправильної інформації, але й буде використано зловмисно, що вплине на репутацію платформи та безпеку активів користувачів.

EIP-6780

Ця пропозиція змінює поведінку попередньої операції самознищення, де контракт не знищується, але відбувається лише переказ токенів, і тільки контракти, створені у тій самій транзакції, що й контракт самознищення, будуть знищені. Вплив цієї EIP відносно значний.

Використання create2 для повторного розгортання контрактів за тією самою адресою для оновлення контрактів більше не підтримується. Цю функціональність слід замінити ERC-2535 або іншими типами контрактів-проксі. (Це може вплинути на безпеку on-chain contractsреалізація оновлюваних контрактів за допомогою create2).

Операція SELFDESTRUCT в смарт-контрактах дозволяє спалювати контракти та відправляти баланс контракту на вказану цільову адресу. У цьому випадку контракт використовує SELFDESTRUCT для спалювання Ether та відправляє спалений Ether на контракт. Однак цей контракт повинен бути створений лише в тій самій транзакції, що й інші контракти (контракти, створені цим контрактом або інші контракти в тій самій транзакції). В іншому випадку Ether буде тільки перекладено без спалювання контракту (наприклад, selfdestruct з бенефіціаром, яким є контракт selfdestruct, що не призведе до будь-яких змін). Це буде мати вплив на всі контрактиякі покладаються на функцію selfdestruct для виведення коштів або інших операцій.

Токен газу, схожий з токеном 1inch CHI, працює наступним чином: зберігання зсуву, завжди розгортання CREATE2 або SELFDESTRUCT на цьому зсуві. Після цього оновлення, якщо контракт на поточному зсуві не був правильно самостійно знищений, наступні CREATE2 не зможуть успішно розгортати контракти.

Ця реалізація пропозиції не може напряму атакувати контракти, але вона пошкодить нормальну логіку існуючих контрактів, які покладаються на операції selfdestruct (контракти, які покладаються тільки на selfdestruct для переказу коштів, не постраждають, але контракти, які вимагають подальших операцій для видалення selfdestruct контрактів, постраждають), що призводить до несподіваної роботи контрактів і може призвести до страйків контрактів, втрати коштів і т.д. (наприклад, контракти, які спочатку використовували create2 для розгортання нових контрактів за початковою адресою та self-destructed початковий контракт для оновлення, більше не можуть бути успішно розгорнуті). На довгострокову перспективу зміна функціональності опкоду може призвести до проблем централізації.

Наприклад, існує існуючий контракт сховища для оновлень:

• Тимчасові контракти зберігання, create2, використовуються для тимчасового резервування коштів для сховища.
• Саморозрушення контракту сховища, перекладення коштів на тимчасовий контракт (переклад коштів без видалення контракту).
• Створіть новий контракт сховища за оригінальною адресою за допомогою create2 (не вдається через те, що оригінальний контракт сховища не був спалено).
• Самознищуйте тимчасовий контракт, щоб повернути кошти до сховища (втрачені кошти, контракт сховища не створений).

Розширене читання:

Оновлення Канкун додатково підвищить конкурентні переваги Ethereum. Однак зміни у основному рівні розумного контракту в цьому оновленні приносять ризики, які впливатимуть на безпечну роботу існуючих DApps. Під час розробки розумного контракту ці зміни та потенційні ризики, які вони можуть призвести, слід тісно контролювати. Ви можете звернутися до Салюса для перевірки ризику або підтримки аудиту, або для подальшого читання, щоб зрозуміти зміни.

Специфікація оновлення мережі Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Контракт Metapod

GasToken2 контракт

Відмова від відповідальності：

1. Ця стаття була перепечатана з [Aicoin]Forward the Original Title‘Salus Insights：坎昆升级前，项目开发者必看的几项安全检查’. All copyrights belong to the original author [ *Odaily Планета Щоденна]. Якщо є зауваження до цього повторного друку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонені.