Лонг кратко: Приближается обновление Cancun, и это обновление в основном включает в себя изменения исполнительного уровня, предложенные шестью EIP: EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780 и EIP-7516. EIP-4844 является главным героем этого обновления, которое направлено на улучшение масштабируемости Ethereum, Падение Стоимость транзакции L2 и увеличение скорости транзакций. Модернизация «Канкуна» была завершена 17 января, 30 января, 7 февраля в Тестовая сеть Ethereum Гёрли, Сеполия и Холески, и запланирована на 13 марта в Ethereum Основная сеть году. Перед обновлением Salus собрал важные соображения безопасности для этого обновления, чтобы разработчики могли проверить их самостоятельно.
Рассмотрение предложения EIP
Официально раскрытые соображения безопасности
Риски, связанные со смарт-контрактами
Подробнее
Рассмотрение предложения EIP
ЭИП-1153
EIP-1153 вводит код операции временного хранилища, который является кодом операции, используемым для рабочего состояния и ведет себя почти так же, как хранилище, но отбрасывается после завершения каждой транзакции. Это означает, что временное хранилище не десериализует значения из хранилища и не сериализует значения в хранилище, поэтому временное хранилище является менее затратным, так как не требует доступа к диску. С помощью двух новых кодов операций, TLOAD и TSTORE (где «T» означает «временный»), смарт-контракт может получить доступ к временному хранилищу. Это предложение направлено на предоставление специализированного и эффективного решения для связи между вложенными фреймворками исполнения Лонга при выполнении транзакций Ethereum.
ЭИП-4788
EIP-4788 направлен на то, чтобы предоставить EVM доступ к корням хэш-дерева блоков Beacon Chain, чтобы обеспечить доступ к этим корням внутри смарт-контракта. Это обеспечивает надежный доступ к состоянию уровня Соглашения, поддерживая варианты использования Лонга, такие как пулы ставок, структуры перераспределения, мосты смарт-контрактов, смягчение последствий MEV и многое другое. Предложение хранит эти корни в Смарт-контракт и использует кольцевой буфер для ограничения потребления хранилища, гарантируя, что каждому Блок выполнения требуется только константа Шорт для представления этой информации.
ЭИП-4844
EIP-4844 представляет новый формат транзакций под названием «Шардинг транзакций BLOB-объектов», предназначенный для масштабирования доступности данных Ethereum простым и совместимым способом. Это делается за счет введения «транзакций с большими двоичными объектами», которые содержат большой объем данных, к которым не может получить доступ выполнение EVM, но которые могут получить доступ к его обещаниям. Этот формат полностью совместим с форматом, используемым полным шардингом в будущем, обеспечивая временное, но значительное облегчение для скользящего масштабирования.
ЭИП-5656
В EIP-5656 представлена новая инструкция EVM, MCOPY, для эффективной репликации областей памяти. Это предложение направлено на Падение накладных расходов, связанных с выполнением операций копирования памяти на EVM, путем прямого включения репликации данных между памятью с помощью инструкции MCOPY. MCOPY ПОЗВОЛЯЕТ ПЕРЕКРЫВАТЬ ИСХОДНЫЙ И ЦЕЛЕВОЙ Адрес Адрес, РАЗРАБОТАН С УЧЕТОМ ОБРАТНОЙ СОВМЕСТИМОСТИ И ПРЕДНАЗНАЧЕН ДЛЯ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ВЫПОЛНЕНИЯ В Лонг СЦЕНАРИЯХ, ВКЛЮЧАЯ СОЗДАНИЕ СТРУКТУРЫ ДАННЫХ, ЭФФЕКТИВНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ И РЕПЛИКАЦИЮ.
ЭИП-6780
EIP-6780 изменяет функциональность кода операции SELFDESTRUCT. В этом предложении SELFDESTRUCT удалит только учетную запись и передаст весь Эфир в той же транзакции, в которой был создан контракт, за исключением того, что при выполнении SELFDESTRUCT контракт не будет удален, а просто передаст весь Эфир указанному месту назначения. Это изменение предназначено для использования деревьев Verkle в будущем, а также для упрощения реализаций EVM и снижения сложности изменений состояния, сохраняя при этом некоторые из распространенных сценариев, используемых SELFDESTRUCT.
ЭИП-7516
В EIP-7516 введена новая инструкция EVM, BLOBBASEFEE, которая возвращает базовое значение комиссии BLOB-объекта при выполнении текущего блока. Эта директива аналогична коду операции BASEFEE в EIP-3198, за исключением того, что она возвращает базовую плату за BLOB-объект, определенную в EIP-4844. Эта функция позволяет контракту программно учитывать цену газа для данных BLOB-объектов, например, позволяя контрактам объединения надежно вычислять затраты на использование данных BLOB-объектов или реализовывать фьючерсы на газ BLOB-объектов на основе этого для сглаживания затрат на данные BLOB-объектов.
Официально раскрытые соображения безопасности
ЭИП-1153
Разработчики смарт-контрактов должны понимать жизненный цикл временных переменных хранения, прежде чем использовать их. Поскольку временное хранилище автоматически очищается в конце транзакции, разработчики смарт-контрактов могут попытаться избежать очистки слотов во время звонков для экономии газа. Однако это может помешать дальнейшему взаимодействию с контрактом в той же транзакции (например, в случае реентерабельной блокировки) или вызвать другие ошибки, поэтому разработчикам смарт-контрактов следует быть осторожными, чтобы сохранять ненулевые значения только при резервировании временного слота. Предназначен для использования будущими вызовами в той же транзакции. SSTORE В противном случае эти коды операций ведут себя точно так же, как и SLOAD, поэтому применяются все общие соображения безопасности, особенно когда речь идет о рисках повторного входа.
Разработчики смарт-контрактов также могут попытаться использовать временное хранилище в качестве альтернативы отображению памяти. Они должны знать, что временное хранилище не удаляется, как память, при возврате или возобновлении вызова, и в этих случаях памяти следует отдавать приоритет, чтобы избежать непредвиденного поведения при повторном входе в ту же транзакцию. Временное хранение в памяти неизбежно является дорогостоящим, что должно было предотвратить такую схему использования. Использование большого лонга сопоставления в памяти может быть лучше достигнуто с помощью списков записей с сортировкой по ключу, а сопоставление в памяти редко требуется в смарт-контракте (т. е. автор знает, что в рабочей среде нет известных вариантов использования).
ЭИП-4844
Этот EIP увеличивает требования к пропускной способности примерно на 0,75 МБ при максимальном лонге на блок маяка. Это на 40% больше, чем теоретический максимальный размер блока (30 Мбит/16 Газ на байт calldata = 1.875 Мбайт), поэтому это не приводит к значительному увеличению пропускной способности в худшем случае. После слияния время блока является статическим, а не непредсказуемым распределением Пуассона, что обеспечивает гарантированный период времени для распространения больших блоков.
Даже при ограниченном объеме данных о вызовах устойчивая нагрузка этого EIP на Лонг ниже, чем у альтернативных вариантов, которые могут привести к падению стоимости данных вызовов, так как вам не нужно хранить большие двоичные объекты так долго, как нагрузка выполнения. Это позволяет реализовать политику, согласно которой эти большие двоичные объекты должны храниться по крайней мере в течение определенного периода времени. Конкретное выбранное значение — это эпоха MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, которая составляет примерно 18 дней с задержкой Лонг по сравнению с рекомендуемой (но еще не реализованной) сменой журнала полезных данных выполнения в один год.
ЭИП-5656
Клиенты должны знать, что их реализации не используют промежуточные буферы (например, функция C stdlibmemmove не использует промежуточные буферы), так как это потенциальный вектор отказа в обслуживании (DoS). Лонг встроенных/стандартных библиотечных функций языка для перемещения байтов здесь имеет правильные характеристики производительности.
Кроме того, анализ атак типа «отказ в обслуживании» (DoS) и атак на нехватку памяти аналогичен другим кодам операции для касания памяти, поскольку расширение памяти следует тем же правилам ценообразования.
ЭИП-6780
СЛЕДУЮЩИЕ ПРИЛОЖЕНИЯ САМОУНИЧТОЖЕНИЯ БУДУТ СКОМПРОМЕТИРОВАНЫ, И ПРИЛОЖЕНИЯ, ИСПОЛЬЗУЮЩИЕ ЕГО ТАКИМ ОБРАЗОМ, БОЛЬШЕ НЕ БУДУТ БЕЗОПАСНЫМИ:
WhereCREATE 2 используется для повторного развертывания контракта в том же расположении, чтобы контракт можно было обновить. Эта функция больше не поддерживается, и вместо нее следует использовать ERC-2535 или другой тип прокси-контракта.
Если контракт основан на сжигании эфира путем принятия контракта SELFDESTRUCT в качестве бенефициара, контракт не создается в той же транзакции.
Риски, связанные со смарт-контрактами
EIP 1153
Рассмотрим два сценария использования кода операции TLOAD и TSTORE:
- Вызываемый контракт использует код операции
- Код операции используется для инициирования контракта на звонок
Риск 1 :
По сравнению с традиционными SSTORE и SLOAD, новое временное хранилище в основном изменяет период хранения данных, данные, хранящиеся в tstore, считываются через tload, и данные будут освобождены после выполнения транзакции, вместо того, чтобы записываться в контракт, поскольку sstore постоянно записывается. Разработчики должны знать особенности Кода операции при использовании Кода операции, чтобы избежать потерь, вызванных неправильным использованием данных, которые не могут быть корректно записаны в контракт. Кроме того, данные tstore являются приватной переменной и могут быть доступны только самому контракту. Если вы хотите использовать данные извне, вы можете передать их только в качестве параметра или проиндексировать их в общедоступной переменной stroage.
Риск 2 :
Еще один потенциальный риск заключается в том, что если разработчики смарт-контрактов не будут должным образом управлять жизненным циклом временных переменных хранения, это может привести к удалению или неправильному сохранению данных в ненадлежащее время. Если контракт планирует использовать данные, хранящиеся во временном хранилище, при последующих вызовах транзакции, но не может должным образом управлять жизненным циклом этих данных, данные могут быть ошибочно переданы или потеряны между различными вызовами, что приведет к логическим ошибкам или нарушениям безопасности. Учитывая, что данные о балансе или квоте аналогичного проекта Токена хранятся некорректно, это приведет к ошибкам в логике контракта и приведет к убыткам. Или использование этого кода операции при установке адреса владельца приведет к тому, что привилегированный адрес будет записан неправильно, что приведет к потере модификации важных параметров контракта.
Рассмотрим смарт-контракт, который использует временное хранилище для временной записи цен транзакций на торговой платформе криптоактивов. Контракт обновляет цену по мере завершения каждой транзакции и позволяет пользователям запрашивать последнюю цену в течение короткого периода времени. Однако, если дизайн контракта не учитывает тот факт, что временное хранение автоматически очищается в конце сделки, то пользователь может получить ошибочную или устаревшую цену в период между окончанием одной сделки и началом следующей. Это может не только привести к тому, что пользователи будут принимать решения на основе дезинформации, но и может быть злонамеренно использовано, что повлияет на репутацию платформы и безопасность активов пользователей.
ЭИП-6780
Предложение изменяет предыдущее поведение кода операции самоуничтожения, не уничтожая контракт, а только передавая токен, и только контракт, созданный в той же транзакции, что и самоуничтожение, будет уничтожен. Влияние этого EIP относительно велико.
Повторно разверните контракт по тому же адресу, что и create 2, чтобы обновить контракт. Эта функция больше не поддерживается, и вместо нее следует использовать ERC-2535 или другой тип прокси-контракта. (Это может повлиять на безопасность ончейн-контрактов, которые используют create 2 для реализации масштабируемых контрактов)
Операция SELFDESTRUCT в смарт-контракте позволяет уничтожить контракт и отправить баланс контракта на указанный адрес назначения. В этом случае контракт использует SELFDESTRUCT для сжигания эфира и отправляет сожженный эфир в контракт. Однако контракт может быть только контрактом, созданным в той же транзакции (контрактом, созданным этим контрактом, или другим контрактом в той же транзакции). В противном случае будет передан только Эфир без разрушения контракта (например, самоуничтожающийся и бенефициар является самоуничтожающимся контрактом, что ничего не изменит). Это повлияет на любые контракты, которые полагаются на самоуничтожение для вывода средств или других операций.
Газовый токен, похожий на 1-дюймовый токен CHI, работает: сохраняйте смещение, всегда выполняйте CREATE 2 или SELFDESTRUCT с этим смещением. После этого обновления, если контракт с текущим смещением еще не был правильно самоуничтожен, последующая инструкция CREATE 2 не сможет успешно развернуть контракт.
Реализация этого предложения не приведет к прямой атаке на контракт, но нанесет ущерб нормальной логике первоначально развернутого контракта, который полагается на операцию самоуничтожения (контракт, который полагается только на самоуничтожение для перевода средств, не будет затронут, и если последующая операция должна потребовать удаления контракта самоуничтожения, он будет затронут), в результате чего контракт не будет работать так, как задумано, и только для контракта и пользователей это может привести к забастовке контракта, потере средств и другому ущербу (например, первоначальному использованию create 2). Разверните новый контракт в исходном адрес, и контракт, который самоуничтожает исходный контракт для обновления, больше не может быть успешно развернут. В долгосрочной перспективе возможность изменения кода операции может привести к проблемам централизации.
Например, существует существующее хранилище контракта хранилища, которое необходимо обновить:
- Create 2 Time Storage Contract используется для временного резервирования средств для хранилища
- Контракт на самоуничтожение хранилища, перевод средств во временный контракт (переводятся только средства, контракт не сжигается)
- Новый контракт хранилища по исходному адресу create 2 (не удалось, так как исходный контракт хранилища не был уничтожен)
- Самоуничтожение временного контракта на возврат средств в хранилище (потеря средств, контракт хранилища не был создан)
Подробнее
Обновление Cancun еще больше усилит конкурентное преимущество Ethereum. Однако это обновление создает риск для изменений в основном уровне смарт-контрактов, что повлияет на безопасную работу существующих DApps. В процессе разработки смарт-контрактов на эти изменения и риски, которые могут возникнуть, также необходимо обратить пристальное внимание. Вы можете связаться с Salus для проверки рисков или поддержки аудита, или вы можете прочитать дальше, чтобы понять изменения.
Спецификация модернизации сети в Канкуне
ЭИП-1153
ЭИП-4788
ЭИП-4844
ЭИП-5656
ЭИП-6780
ЭИП-7516
Контракт Metapod
Контракт GasToken 2
