*Forward the Original Title: Перед обновлением Канкуна — несколько проверок безопасности, обязательных для разработчиков проектов

Кратко: Приближается обновление Канкун, которое включает шесть предложенных EIP-изменений, в основном EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 и EIP-7516. EIP-4844 сосредотачивается на увеличении масштабируемости Ethereum, снижении затрат на транзакции и ускорении транзакций для решений 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 per calldata byte = 1,875M байт), поэтому это не значительно увеличивает пропускную способность в крайних случаях. После слияния времена блоков статичны, а не непредсказуемо распределены по Пуассону, что обеспечивает гарантированный временной интервал для распространения больших блоков.

Даже при ограниченных данных вызова постоянная нагрузка этого EIP существенно ниже, чем альтернативные решения, которые могли бы снизить стоимость данных вызова, потому что для Blob-хранения не требуется сохранять тот же срок, что и для выполнения нагрузки. Это делает возможным реализацию стратегий, которые требуют, чтобы эти блобы сохранялись по крайней мере в течение определенного периода времени. Выбранное конкретное значение - это эпоха MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, которая составляет примерно 18 дней, намного короче, чем предлагаемое (но еще не реализованное) время вращения в один год для выполнения историй действительных полезных нагрузок.

EIP-5656

Клиентам следует помнить, что их реализации не используют промежуточные буферы (например, функция memmove стандартной библиотеки C не использует промежуточные буферы), поскольку это потенциальный вектор отказа в обслуживании (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 или другие типы прокси-контрактов. (Это может повлиять на безопасность контракты на цепиреализация обновляемых контрактов с использованием create2).

Операция SELFDESTRUCT в умных контрактах позволяет сжигать контракты и отправлять баланс контракта на указанный адрес назначения. В этом случае контракт использует SELFDESTRUCT для сжигания Эфира и отправки сожженного Эфира контракту. Однако этот контракт должен быть создан только в той же транзакции, что и другие контракты (контракты, созданные этим контрактом или другими контрактами в той же транзакции). В противном случае Эфир будет только передан без сжигания контракта (например, selfdestruct с выгодоприобретателем, являющимся контрактом selfdestruct, что не приведет к каким-либо изменениям). Это повлияет на все контрактыкоторые полагаются на функцию selfdestruct для вывода средств или других операций.

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

Этот проект не может напрямую атаковать контракты, но он повредит нормальную логику существующих контрактов, которые полагаются на операции selfdestruct (контракты, которые полагаются только на selfdestruct для передачи средств, не затрагиваются, но контракты, требующие последующих операций для удаления контрактов selfdestruct, затрагиваются), что может привести к непредвиденной работе контрактов и вызвать забастовки контрактов, потерю средств и т. д. (например, контракты, которые изначально использовали create2 для развертывания новых контрактов на исходном адресе и самоуничтожали исходный контракт для обновления, больше не могут быть успешно развернуты). В долгосрочной перспективе изменение функциональности опкода может привести к проблемам централизации.

Например, существует существующий контракт хранилища для обновлений:

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

Расширенное чтение:

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

Спецификация обновления сети Cancun

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Контракт Metapod

Контракт GasToken2

Disclaimer：

1. Эта статья взята из [Aicoin], Пересылайте оригинальный заголовок «Salus Insights: до обновления Канкуна, несколько обязательных проверок безопасности для разработчиков проектов». Все авторские права принадлежат оригинальному автору [*Odaily Планета Ежедневно]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.