Лонг коротка історія: Наближається оновлення Канкуна, і це оновлення в основному включає зміни виконавчого рівня, запропоновані шістьма EIP: EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 та EIP-7516. EIP-4844 є головним героєм цього оновлення, яке спрямоване на покращення масштабованості Ethereum, Падіння Вартість транзакції L2 та збільшення швидкості транзакцій. Оновлення Cancun було завершено 17 січня, 30 січня, 7 лютого в Ethereum Goerli, Sepolia та Holesky Тестова мережа, а активацію планується на 13 березня у Ethereum Основна мережа році. Перед оновленням Salus зібрав важливі міркування безпеки для цього оновлення, щоб розробники могли перевірити їх самостійно.
Розгляд пропозицій EIP
Офіційно оприлюднені міркування безпеки
Смарт-контракт супутні ризики
Читати далі
Розгляд пропозицій EIP
EIP-1153
EIP-1153 вводить ефемерні Код операції зберігання, які Код операції використовуються для робочого стану і поводяться майже так само, як і сховище, але відкидаються після завершення кожної транзакції. Це означає, що тимчасове сховище не десеріалізує значення зі сховища та не серіалізує значення до сховища, тому тимчасове сховище є дешевшим, оскільки не потребує доступу до диска. Завдяки двом новим кодам операцій, TLOAD і TSTORE (де «T» означає «тимчасовий»), Смарт-контракт можете отримати доступ до тимчасового сховища. Ця пропозиція має на меті забезпечити спеціальне та ефективне рішення для зв’язку між Лонг вкладеними фреймворками виконання у виконанні транзакцій Ethereum.
EIP-4788
EIP-4788 має на меті відкрити коріння хеш-дерева блоків Beacon Chain Blocks для EVM, щоб забезпечити доступ до цих коренів всередині Смарт-контракт. Це забезпечує недовірчий доступ до стану Консенсус рівня, підтримуючи Лонг випадки використання, такі як пули стейкінгу, структури переубору, Смарт-контракт мости, пом’якшення наслідків MEV тощо. Пропозиція зберігає ці корені через Смарт-контракт і використовує кільцевий буфер для обмеження споживання пам’яті, гарантуючи, що кожному виконанню Блок потрібен лише постійний Шорт для представлення цієї інформації.
EIP-4844
EIP-4844 представляє новий формат транзакцій під назвою «Шардинг Blob Transactions», призначений для масштабування доступності даних Ethereum простим і сумісним із форвардами способом. Ця пропозиція робить це, вводячи «транзакції з перенесенням блобів», які містять велику кількість даних, до яких не може отримати доступ виконання EVM, але може отримати доступ до його промісів. Цей формат повністю сумісний з форматом, який використовується повними Шардинг в майбутньому, забезпечуючи тимчасове, але значне полегшення для масштабування прокату.
EIP-5656
EIP-5656 представляє нову інструкцію EVM, MCOPY, для ефективної реплікації областей пам’яті. Ця пропозиція має на меті Падіння накладні витрати на виконання операцій копіювання пам’яті на EVM шляхом безпосереднього забезпечення реплікації даних між пам’яттю за допомогою інструкції MCOPY. MCOPY ДОЗВОЛЯЄ ПЕРЕКРИВАТИ ВИХІДНИЙ І ЦІЛЬОВИЙ Адреса Адреса, РОЗРОБЛЕНИЙ З УРАХУВАННЯМ ЗВОРОТНОЇ СУМІСНОСТІ ТА ПРИЗНАЧЕНИЙ ДЛЯ ПІДВИЩЕННЯ ЕФЕКТИВНОСТІ ВИКОНАННЯ В Лонг СЦЕНАРІЯХ, ВКЛЮЧАЮЧИ ПОБУДОВУ СТРУКТУРИ ДАНИХ, ЕФЕКТИВНИЙ ДОСТУП ДО ОБ’ЄКТІВ У ПАМ’ЯТІ ТА РЕПЛІКАЦІЮ.
EIP-6780
EIP-6780 змінює функціональність Код операції SELFDESTRUCT. У цій пропозиції SELFDESTRUCT лише видалить обліковий запис і перенесе всі Етер у тій самій транзакції, що й контракт, за винятком того, що коли SELFDESTRUCT буде виконано, контракт не буде видалено, а просто переведе всі Етер до вказаного пункту призначення. Ця зміна призначена для використання дерев Веркла в майбутньому та має на меті спростити реалізацію EVM та зменшити складність змін стану, зберігаючи при цьому деякі загальні сценарії, що використовуються SELFDESTRUCT.
EIP-7516
EIP-7516 представляє нову інструкцію EVM, BLOBBASEFEE, яка повертає значення базової комісії BLOB у поточному виконанні блоку. Ця директива подібна до Код операції BASEFEE в EIP-3198, за винятком того, що вона повертає базову комісію BLOB, як визначено EIP-4844. Ця функція дозволяє контракту програмно враховувати ціну газу на дані BLOB, наприклад, дозволяючи зведеним контрактам без довіри розраховувати вартість використання даних BLOB, або впроваджувати ф’ючерси на газ на BLOB-об’єкти на основі цього, щоб згладити витрати на дані BLOB.
Офіційно розкриті міркування безпеки
EIP-1153
Смарт-контракт розробники повинні розуміти життєвий цикл тимчасових змінних сховища, перш ніж їх використовувати. Оскільки тимчасове сховище автоматично очищається в кінці транзакції, Смарт-контракт розробники можуть намагатися уникати звільнення слотів під час дзвінків для економії газу. Однак це може запобігти подальшій взаємодії з контрактом у тій самій транзакції (наприклад, у випадку блокування повторного входу) або спричинити інші помилки, тому Смарт-контракт розробники повинні бути обережними, зберігаючи ненульові значення лише тоді, коли тимчасовий слот зарезервовано. Призначений для використання майбутніми викликами в тій самій транзакції. SSTORE В іншому ці коди операцій поводяться точно так само, як і SLOAD, тому застосовуються всі загальні міркування безпеки, особливо коли мова йде про ризики повторного входу.
Смарт-контракт розробники також можуть спробувати використовувати тимчасове сховище як альтернативу відображенню пам’яті. Вони повинні знати, що ефемерне сховище не відкидається, як пам’ять, коли виклик повертається або відновлюється, і пам’ять повинна бути пріоритетною в цих випадках використання, щоб уникнути несподіваної поведінки при повторному вході в ту саму транзакцію. Тимчасове зберігання пам’яті обов’язково дороге, що повинно було запобігти такій схемі використання. Велика Лонг використання відображення в пам’яті може бути краще досягнута за допомогою списків записів, відсортованих за ключами, а відображення в пам’яті рідко потрібне в Смарт-контракт (тобто автор знає, що немає відомих варіантів використання у виробництві).
EIP-4844
Цей EIP збільшує вимоги до пропускної здатності приблизно на 0,75 МБ при максимальному Лонг на блок маяка. Це на 40% більше, ніж сьогоднішній теоретичний максимальний розмір Блок (30 M Gas / 16 Gas на байт calldata = 1,875 M байт), тому це не значно збільшує пропускну здатність у найгіршому випадку. Після злиття Блок час є статичним, а не непередбачуваним розподілом Пуассона, що забезпечує гарантований період часу для поширення великих Блок.
Навіть з обмеженими даними про виклики стійке навантаження цього EIP Лонг нижче, ніж альтернативи, які можуть Падіння вартість даних про виклики, оскільки вам не потрібно зберігати BLOB-об’єкти так довго, як навантаження виконання. Це дає можливість впровадити політику, згідно з якою ці плями повинні зберігатися принаймні протягом певного періоду часу. Конкретним вибраним значенням є епоха MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, яка становить приблизно 18 днів, із затримкою Лонг порівняно з рекомендованою (але ще не реалізованою) однорічною ротацією історії корисного навантаження виконання.
EIP-5656
Клієнти повинні знати, що їхні реалізації не використовують проміжні буфери (наприклад, функція C stdlibmemmove не використовує проміжні буфери), оскільки це потенційний вектор відмови в обслуговуванні (DoS). Лонг вбудованих/стандартних бібліотечних функцій мови для переміщення байтів мають тут правильні характеристики продуктивності.
Крім цього, аналіз атак типу «відмова в обслуговуванні» (DoS) і виснаження пам’яті такий самий, як і інші Код операції дотику до пам’яті, оскільки розширення пам’яті відбувається за тими ж правилами ціноутворення.
EIP-6780
НАСТУПНІ ПРОГРАМИ САМОЗНИЩЕННЯ БУДУТЬ СКОМПРОМЕТОВАНІ, І ПРОГРАМИ, ЯКІ ВИКОРИСТОВУЮТЬ ЙОГО ТАКИМ ЧИНОМ, БІЛЬШЕ НЕ Є БЕЗПЕЧНИМИ:
WhereCREATE 2 використовується для перерозподілу контракту в тому самому місці, щоб контракт можна було оновити. Ця функція більше не підтримується, і замість неї слід використовувати ERC-2535 або інший тип проксі-контракту.
Якщо контракт ґрунтується на спалюванні Етер, беручи в якості бенефіціара контракт САМОЗНИЩЕННЯ, контракт не створюється в тій самій угоді.
Ризики, пов’язані зі смарт-контрактами
EIP 1153
Розглянемо два сценарії з використанням Код операції TLOAD і TSTORE:
- У контракті, що викликається, використовується Код операції
- Код операції використовується для ініціювання договору про виклик
Ризик 1 :
У порівнянні з традиційними SSTORE і SLOAD, нове тимчасове сховище в основному змінює період зберігання даних, дані, що зберігаються tstore, зчитуються через tload, і дані будуть вивільнятися після виконання транзакції, а не бути записаними в контракт, оскільки sstore записується на постійній основі. Розробники повинні враховувати особливості Код операції при використанні Код операції, щоб уникнути збитків, викликаних некоректним використанням даних, які не можуть бути правильно прописані в договорі. Крім того, дані tstore є приватною змінною і доступ до них може отримати лише сам контракт. Якщо ви хочете використовувати дані ззовні, ви можете передати їх лише як параметр або помістити в публічну змінну строажу.
Ризик 2 :
Інший потенційний ризик полягає в тому, що якщо Смарт-контракт розробники не керують належним чином життєвим циклом тимчасових змінних сховища, це може призвести до неналежного очищення або неправильного збереження даних. Якщо контракт планує використовувати дані, що зберігаються в тимчасовому сховищі, під час подальших викликів транзакції, але не може належним чином керувати життєвим циклом цих даних, дані можуть бути помилково передані або втрачені між різними викликами, що призведе до логічних помилок або порушень безпеки. Враховуючи, що дані про баланс або надбавки аналогічного Токен проекту зберігаються некоректно, це призведе до помилок у логіці контракту та спричинить збитки. Або використання цієї Код операції при встановленні власника Адреса призведе до того, що привілейовані Адреса будуть записані некоректно, тим самим втрачаючи модифікацію важливих параметрів договору.
Розглянемо Смарт-контракт, який використовує тимчасове сховище для тимчасового запису цін транзакцій на Криптоактиви торговій платформі. Контракт оновлює ціну в міру завершення кожної транзакції та дозволяє користувачам запитувати останню ціну протягом короткого періоду часу. Однак, якщо дизайн контракту не враховує той факт, що перехідне зберігання автоматично очищається після закінчення угоди, то користувач може отримати помилкову або застарілу ціну в період між закінченням однієї угоди і початком наступної. Це може не тільки змусити користувачів приймати рішення на основі дезінформації, але й зловмисно скористатися, що вплине на репутацію платформи та безпеку активів користувачів.
EIP-6780
Пропозиція змінює попередню поведінку Код операції самознищення, не знищуючи контракт, а лише передаючи токен, і знищуватиметься лише контракт, створений у тій самій транзакції, що й самознищення. Вплив цього ЕІП відносно великий.
Перерозподіліть контракт у той самий Адреса зі створенням 2 для оновлення контракту. Ця функція більше не підтримується, і замість неї слід використовувати ERC-2535 або інший тип проксі-контракту. (Це може вплинути на безпеку ончейн-контрактів, які використовують create 2 для реалізації масштабованих контрактів)
Операція САМОЗНИЩЕННЯ в Смарт-контракт дозволяє знищити контракт і відправити залишок контракту в зазначений пункт призначення Адреса. У цьому випадку контракт використовує SELFDESTRUCT для спалювання Етер і відправляє спалену Етер до контракту. Однак договором може бути тільки контракт, створений в одній і тій же операції (контракт, створений цим договором, або інший договір в тій же угоді). В іншому випадку буде передано лише Етер без руйнування контракту (наприклад, самознищувальний, а бенефіціар – це самознищувальний контракт, який нічого не змінить). Це вплине на будь-які контракти, які покладаються на самознищення для виведення коштів або інших операцій.
Газовий жетон, подібний до 1inch CHI, Токен працює: зберігайте зсув, завжди виконуйте CREATE 2 або SELFDESTRUCT на цьому зміщенні. Після цього оновлення, якщо контракт з поточним зміщенням ще не самоліквідувався належним чином, наступний CREATE 2 не зможе успішно розгорнути контракт.
Реалізація цієї пропозиції не призведе до прямої атаки на контракт, але це зашкодить нормальній логіці початкового розгорнутого контракту, який покладається на операцію самознищення (контракт, який покладається лише на самознищення для переказу коштів, не постраждає, і якщо подальша операція вимагатиме видалення контракту про самознищення, це вплине на нього), що призведе до того, що контракт не працюватиме належним чином, і лише для контракту та користувачів, це може призвести до страйку контракту, втрати коштів та іншої шкоди (наприклад, початкове використання create 2). Розгорніть новий контракт у початковому Адреса, і контракт, який самознищує початковий контракт на оновлення, більше не може бути успішно розгорнутий). У довгостроковій перспективі можливість модифікувати Код операції може призвести до проблем із централізацією.
Наприклад, існує наявне сховище контрактів сховища, яке потрібно оновити:
- Створити 2 Договір тимчасового зберігання використовується для тимчасового резервування коштів для сховища
- Договір про самознищення сховища, переведення коштів на тимчасовий контракт (перераховуються тільки кошти, договір не спалюється)
- Новий контракт на сховище в початковому Адреса створити 2 (не вдалося, оскільки початковий контракт сховища не був знищений)
- Самоліквідаційний тимчасовий договір про повернення коштів у сховище (втрата коштів, договір сховища не був створений)
Читати далі
Оновлення Cancun ще більше посилить конкурентну перевагу Ethereum. Однак це оновлення створює ризик змін на рівні ядра Смарт-контракт, що вплине на безпечну роботу існуючих DApps. У процесі Смарт-контракт розвитку на ці зміни і ризики, які можуть виникнути, також потрібно звертати пильну увагу. Ви можете зв’язатися з Salus для перевірки ризиків або аудиторської підтримки, або ви можете прочитати далі, щоб зрозуміти зміни.
Специфікація оновлення мережі Канкуна
ЄІП-1153
ЄІП-4788
ЄІП-4844
ЄІП-5656
ЄІП-6780
ЄІП-7516
Контракт Metapod
Контракт на GasToken 2
