Функция fallback

Что такое функция fallback?

Функция fallback — это специальная функция Solidity, которая обрабатывает внешние вызовы, не соответствующие ни одной другой функции смарт-контракта.

Она служит последним вариантом маршрутизации вызова, когда Solidity не может определить обычную функцию по переданным данным транзакции.

Функция fallback также может выполняться при вызове без данных, если в контракте нет отдельной функции receive.

Эту функцию широко используют в криптовалютных приложениях, в том числе в обновляемых смарт-контрактах, системах прокси, модульных кошельках, платежных контрактах и пользовательских маршрутизаторах вызовов.

Согласно официальной документации Solidity, контракт может содержать не более одной функции fallback.

У функции fallback должна быть внешняя видимость, поскольку она предназначена для обработки вызовов, поступающих извне контракта.

Она может быть payable, если контракту нужно принимать нативную криптовалюту через нераспознанный вызов.

В расширенном варианте функции она также может анализировать полные данные транзакции и возвращать необработанные данные ответа.

Функция fallback не является универсальным обработчиком всех ошибок при выполнении операций со смарт-контрактом.

Она выполняется только при определенных условиях маршрутизации вызовов, заданных Solidity и Ethereum Virtual Machine.

Почему она называется функцией fallback?

Слово fallback означает альтернативное действие, которое используется, когда предпочтительное или ожидаемое действие недоступно.

При вызове обычной функции смарт-контракта Solidity сначала пытается сопоставить данные транзакции с одной из объявленных функций контракта.

Если совпадение не найдено, контракт переключается на функцию fallback.

Это позволяет разработчикам задавать поведение контракта в случае, когда кошелек, смарт-контракт или приложение отправляет неподдерживаемый вызов.

Функция fallback может отклонить вызов, принять платеж, записать событие, вернуть данные или перенаправить вызов другому контракту.

Если в контракте нет подходящей функции fallback, неподдерживаемый вызов обычно отменяется.

Когда вызывается функция fallback?

Функция fallback вызывается, когда внешний вызов поступает в смарт-контракт, но переданный селектор функции не соответствует ни одной обычной функции.

Она также вызывается при пустых данных calldata, если контракт не определяет функцию receive.

Вызов с непустыми данными может попасть в функцию fallback независимо от того, передается ли вместе с ним нативная криптовалюта.

Если вызов содержит ненулевую сумму криптовалюты, функция fallback должна быть payable.

Неплатежеспособная функция fallback отклоняет нераспознанный вызов, при котором передается стоимость.

Если данные пусты и в контракте определена функция receive, вызов попадает в нее.

Таким образом, роль функции fallback зависит от того, есть ли в контракте также функция receive.

Как работает маршрутизация функций в смарт-контракте

Внешние вызовы смарт-контрактов обычно содержат закодированные данные транзакции, называемые calldata.

Первые четыре байта стандартного вызова функции содержат селектор функции.

Спецификация Solidity ABI определяет селектор как первые четыре байта хеша Keccak-256 канонической сигнатуры функции.

Каноническая сигнатура состоит из имени функции и типов ее параметров.

Solidity сравнивает входящий селектор с селекторами публичных и внешних функций контракта.

Если совпадение найдено, соответствующая функция обрабатывает вызов.

Если совпадения нет, Solidity направляет вызов в функцию fallback, если она существует.

По коротким данным calldata длиной менее четырех байт обычно нельзя определить обычную функцию Solidity, поэтому такой вызов может попасть в функцию fallback.

Для пустых данных действует отдельное правило маршрутизации, согласно которому приоритет отдается функции receive.

Функция fallback и функция receive

Функции fallback и receive — это отдельные точки входа Solidity с разным назначением.

Функция receive предназначена специально для вызовов с пустыми данными calldata.

Функция fallback в первую очередь обрабатывает вызовы с данными, которые не соответствуют ни одной объявленной функции.

Функция receive всегда имеет атрибут payable, поскольку ее основное назначение — принимать нативную криптовалюту.

Функция fallback может принимать средства только в том случае, если разработчик явно указал для нее атрибут payable.

Если в контракте определены обе функции, перевод с пустыми данными попадает в receive.

Нераспознанный вызов с данными попадает в fallback.

Если функция receive отсутствует, функция fallback с атрибутом payable может обработать перевод с пустыми данными.

Актуальные рекомендации Solidity по приему криптовалюты советуют определять функцию receive, если в контракте есть функция fallback с атрибутом payable.

Такое разделение помогает отличать намеренный платеж от вызова функции с неправильной кодировкой.

Функция fallback и обычная функция

У обычной функции Solidity есть объявленное имя и, как правило, собственный селектор.

Приложения могут вызывать обычную функцию через известный интерфейс контракта.

У функции fallback нет обычного имени для прямого вызова.

У нее нет отдельного селектора, с помощью которого пользователи вызывали бы ее напрямую.

Вместо этого она обрабатывает вызовы, не соответствующие обычному интерфейсу контракта.

В контракте может быть множество обычных функций, но только одна функция fallback.

Обычные функции обычно должны содержать основную бизнес-логику децентрализованного приложения.

У функции fallback должно быть узкое и четко документированное назначение, если только она намеренно не используется как маршрутизатор прокси.

Функция fallback и обработка ошибок

Функция fallback не выполняется каждый раз, когда другая функция смарт-контракта завершается ошибкой.

Если данные calldata соответствуют обычной функции, но та впоследствии отменяет операцию, функция fallback не вызывается.

Если соответствующая функция отклоняет платеж, поскольку у нее нет атрибута payable, Solidity не перенаправляет платеж в функцию fallback.

Если селектор функции правильный, но аргументы некорректны, соответствующий вызов обычно отменяется на этапе декодирования.

Не активируют функцию fallback и ошибка проверки условия, арифметическая проверка, правило контроля доступа, внешний вызов или пользовательская ошибка.

Разработчики должны обрабатывать такие сбои обычными средствами: проверкой ошибок, контролем возвращаемых значений, пользовательскими ошибками или подходящей логикой try/catch.

Функция fallback обрабатывает нераспознанные вызовы, а не сбои внутри вызовов, соответствующих функции.

Что такое функция fallback с атрибутом payable?

Функция fallback с атрибутом payable может принимать нативную криптовалюту, прикрепленную к нераспознанному внешнему вызову.

Отправленная сумма доступна через поле значения транзакции.

Функция fallback также может получить адрес отправителя.

При наличии достаточного количества газа функция fallback с атрибутом payable может менять состояние, генерировать событие, перенаправлять вызов или выполнять другое разрешенное действие.

Атрибут payable у функции fallback налагает на контракт финансовые обязательства.

Контракту могут потребоваться надежный учет баланса, контролируемый вывод средств, процедуры на случай чрезвычайной ситуации и защита от повторного входа.

Если контракт не предназначен для хранения криптовалюты, ему обычно следует отклонять неожиданные платежи.

Атрибут payable следует использовать только тогда, когда он нужен для конкретной функции протокола.

Что такое функция fallback без атрибута payable?

Функция fallback без атрибута payable может обрабатывать нераспознанные вызовы, при которых нативная криптовалюта не передается.

Нераспознанный вызов с ненулевым значением будет отменен, если функция fallback не имеет атрибута payable.

Такая схема подходит, когда контракту нужна пользовательская маршрутизация или журналирование, но он не должен принимать средства.

Функция fallback без атрибута payable также может явно отклонять неподдерживаемые селекторы функций.

Отклонение неизвестных вызовов может помочь пользователям и приложениям обнаружить, что они используют неверный интерфейс.

Какую информацию может считывать функция fallback?

Функция fallback может получить адрес, с которого инициирован текущий вызов.

Если функция имеет атрибут payable, она может получить сумму нативной криптовалюты, переданную вместе с вызовом.

Она может анализировать все данные calldata, переданные вызывающей стороной.

Полные данные calldata включают возможный селектор и любые дополнительные закодированные значения.

Параметризованная форма функции fallback может получить эти данные в виде последовательности байтов.

Она также может напрямую возвращать необработанные байты вызывающей стороне.

Solidity не применяет стандартную ABI-кодировку автоматически к данным, возвращаемым функцией fallback в необработанном виде.

Это особенно полезно для прокси-контрактов, которым нужно вернуть ответ реализации в точности в исходном виде.

Следует ли функции fallback декодировать calldata?

Функция fallback может вручную анализировать и декодировать calldata.

Первые четыре байта можно сравнить с ожидаемыми селекторами.

Оставшиеся байты можно декодировать в соответствии с ожидаемыми типами параметров.

Однако документация Solidity рекомендует прибегать к ручному декодированию в fallback только в крайнем случае.

Обычные функции с именами обеспечивают более понятные интерфейсы, безопасное автоматическое декодирование и более простую интеграцию.

При ручном декодировании необходимо проверять длину calldata, смещения, типы и поддерживаемые селекторы.

Некорректные данные следует отклонять до изменения любого важного состояния.

Неправильное декодирование может привести к неожиданному поведению, отмене транзакций или уязвимостям безопасности.

Функции fallback в обновляемых прокси-контрактах

Обновляемые прокси-контракты — один из важнейших вариантов использования функций fallback в криптовалютных приложениях.

Прокси отделяет адрес контракта и хранящееся состояние от кода, содержащего бизнес-логику приложения.

Пользователи отправляют транзакции на адрес прокси.

В прокси хранится адрес контракта реализации, содержащего действующую логику.

Вызовы, не соответствующие функциям, непосредственно определенным в прокси, попадают в его функцию fallback.

Функция fallback перенаправляет такие вызовы контракту реализации с помощью delegatecall.

Документация Ethereum об обновлении прокси поясняет, что такая структура позволяет менять бизнес-логику, сохраняя прежний адрес прокси для взаимодействия с пользователями.

После замены реализации прокси сохраняет балансы и данные приложения.

Такой подход позволяет исправлять ошибки и добавлять функции, не переводя каждого пользователя на новый адрес контракта.

Что такое delegatecall?

Delegatecall — это операция Ethereum Virtual Machine, которая выполняет код другого контракта в контексте вызывающего контракта.

В системе прокси код предоставляется контрактом реализации.

Адрес, баланс криптовалюты и постоянное хранилище предоставляет прокси.

Исходные адрес отправителя и значение транзакции остаются доступными во время делегированного выполнения.

Таким образом, реализация работает так, будто ее логика является частью прокси.

EIP-7 ввел delegatecall как низкоуровневую операцию для выполнения внешнего кода с сохранением контекста отправителя и значения исходного вызова.

Delegatecall обладает широкими возможностями, поскольку реализация может считывать и изменять хранилище прокси.

По той же причине эта операция опасна.

Вредоносная или несовместимая реализация может нарушить учет балансов, разрешений, данных о владельцах или других важных состояний.

Как функция fallback прокси маршрутизирует вызов

Сначала прокси получает полные данные calldata пользователя.

Его функция fallback определяет текущий адрес реализации.

Прокси перенаправляет исходные данные calldata этой реализации через delegatecall.

Реализация выполняет свою логику, используя хранилище прокси.

Прокси получает данные ответа реализации.

Если делегированный вызов выполнен успешно, прокси возвращает исходной вызывающей стороне тот же ответ.

Если делегированный вызов завершился ошибкой, прокси должен передать вызывающей стороне исходные сведения об ошибке.

Неправильное перенаправление может скрыть ошибки, изменить возвращаемые данные или привести к их некорректной интерпретации интеграциями.

Ячейки хранилища прокси

Прокси должен где-то хранить в постоянном хранилище адрес реализации.

Это место не должно совпадать с ячейками переменных, используемых контрактом реализации.

ERC-1967 определяет стандартизированные ячейки хранилища для сведений о реализации прокси, beacon и администраторе.

Эти ячейки выбираются так, чтобы не совпадать с обычными слотами хранилища, назначаемыми компилятором Solidity.

Стандартизированные ячейки также помогают обозревателям блокчейна и инструментам разработки определять связи между прокси и другими контрактами.

Использование установленной ячейки хранилища снижает вероятность случайного совпадения, но не устраняет все риски обновления.

Версии реализации по-прежнему должны сохранять совместимую структуру хранилища.

Риск несовместимости структуры хранилища

При обновлении контракта реализации прокси сохраняет существующие данные.

Новая реализация должна интерпретировать эти данные так же, как предыдущая.

Изменение порядка существующих переменных состояния может привести к тому, что одно значение будет считано как другое.

Изменение типа переменной может исказить смысл данных или сделать их недоступными.

Изменение наследования также может изменить ожидаемую структуру хранилища.

Новые переменные состояния необходимо добавлять в соответствии с правилами хранилища выбранной архитектуры прокси.

Транзакция обновления может завершиться успешно, но при этом незаметно повредить хранилище контракта.

Поэтому совместимость структуры хранилища необходимо проверять перед каждым обновлением реализации.

Коллизия селекторов функций

Селектор функции состоит всего из четырех байтов.

Теоретически две разные сигнатуры функций могут иметь одинаковый селектор.

Такое событие называется коллизией селекторов.

Коллизия особенно важна, когда вызываемые функции определены и в прокси, и в его реализации.

Прокси может перехватить селектор, который пользователь рассчитывал направить реализации.

В ERC-1967 поясняется, что конфликты селекторов могут привести к неожиданным ответам и даже скрыть вредоносное поведение прокси.

Разработчикам следует проверять все селекторы функций прокси, реализации, административных функций и запланированных обновлений.

Само по себе имя функции не подтверждает уникальность ее селектора в нескольких контрактах.

Риск полномочий на обновление

В обновляемом прокси обычно есть аккаунт или механизм управления, которому разрешено менять адрес реализации.

Контролирующий эти полномочия может менять код, выполняемый через функцию fallback.

Скомпрометированный ключ обновления может установить реализацию, которая переведет активы или изменит балансы аккаунтов.

Злонамеренный администратор также может заменить легитимную логику вредоносной.

Следует проверить адрес администратора, порог числа подписантов, процесс управления, задержку выполнения, полномочия на случай чрезвычайной ситуации и историю обновлений.

Проверенный исходный код функции fallback прокси не гарантирует безопасность всех будущих реализаций.

Возможность обновления предполагает постоянное доверие к управлению и операционным процессам.

Функции fallback в контрактах Diamond

Контракт Diamond направляет разные селекторы функций нескольким контрактам реализации, называемым фасетами.

Функция fallback анализирует входящий селектор и определяет, какой фасет отвечает за эту функцию.

Затем она перенаправляет вызов выбранному фасету через delegatecall.

ERC-2535 определяет архитектуру прокси с несколькими фасетами для модульных систем смарт-контрактов.

Такая схема может поддерживать приложения, логика которых слишком велика для одного контракта реализации.

Также можно добавлять, заменять или удалять отдельные группы функций.

Гибкость увеличивает сложность работы с селекторами, хранилищем, инициализацией, разрешениями и обновлениями.

Проверка только одного фасета не раскрывает все функции, доступные через адрес Diamond.

Функции fallback в модульных смарт-аккаунтах

В смарт-аккаунтах могут использоваться обработчики fallback для добавления модульных функций.

Обработчик может поддерживать подписи, обратные вызовы токенов, восстановление аккаунта, временные разрешения или интерфейсы для конкретного приложения.

ERC-7579 описывает обработчики fallback как модули, расширяющие функциональность смарт-аккаунта.

Аккаунт должен контролировать, какие обработчики можно устанавливать, заменять и удалять.

Несанкционированный обработчик может создать возможность для неожиданного поведения аккаунта.

Пользователям кошелька следует учитывать, что замена модуля fallback может изменить реакцию аккаунта на внешние вызовы.

Газ и функции fallback

Функция fallback может выполнять сложные операции, если вызывающая сторона предоставила достаточно газа.

Не следует рассчитывать, что каждый вызывающий предоставит одинаковое количество газа.

Некоторые старые методы перевода криптовалюты передают контракту-получателю лишь небольшое количество газа.

В актуальной документации Solidity указано, что send и transfer объявлены устаревшими и должны быть удалены.

Небольшого лимита газа может быть недостаточно для обновления хранилища, дополнительных переводов, создания контрактов или дорогостоящих внешних вызовов.

Затраты газа также могут измениться после обновления сети.

Поэтому в платежном процессе не следует полагаться на сложную логику функции fallback.

Разработчикам не следует считать небольшой лимит газа единственной защитой от вредоносных обратных вызовов.

Риск повторного входа через функцию fallback

При наличии достаточного количества газа функция fallback может вызвать другой контракт.

Она может повторно обратиться к контракту, который изначально отправил криптовалюту или инициировал взаимодействие.

Это может привести к повторному входу, если отправляющий контракт не завершил учет до внешнего вызова.

Рекомендации Solidity по защите от повторного входа поясняют, что внешние вызовы контрактов могут возвращать управление до завершения исходной операции.

Контрактам следует проверять условия до выполнения внешних вызовов.

Перед передачей управления ненадежному контракту необходимо обновлять важное внутреннее состояние.

Дополнительным уровнем защиты может стать надлежащая защита от повторного входа.

Любой внешний вызов следует рассматривать как возможное выполнение ненадежного кода.

Риск отказа в обслуживании

Функция fallback может намеренно или случайно отменить операцию.

Если другой контракт должен успешно выполнить платеж, прежде чем продолжить более крупную операцию, получатель может заблокировать эту операцию.

Функция fallback также может потреблять слишком много газа или выполнять дорогостоящие внешние вызовы.

Это особенно опасно, если из-за одного неудачного платежа отменяется весь цикл распределения средств.

Рекомендации Solidity по отправке криптовалюты предлагают использовать модель с выводом средств для многих платежных систем.

Такая модель позволяет каждому получателю самостоятельно забирать средства.

В этом случае поведение функции fallback одного получателя с меньшей вероятностью заблокирует выплаты другим пользователям.

Неожешанный успех низкоуровневого вызова

Низкоуровневый вызов сообщает, успешно ли выполнился код целевого контракта или операция была отменена.

Успешный результат не доказывает, что требуемая именованная функция существует.

Неизвестный селектор может попасть в разрешающую вызов функцию fallback и успешно выполниться.

Контракт, который проверяет только статус выполнения, может ошибочно предположить, что запрошенная операция состоялась.

При использовании низкоуровневых вызовов разработчикам следует проверять возвращаемые данные и ожидаемые изменения состояния.

Если целевая функция уже известна, типизированный интерфейс обычно безопаснее.

Функции fallback и нативная криптовалюта

Функция fallback с атрибутом payable может принимать нативную криптовалюту через нераспознанные вызовы.

Если функции receive нет, она также может обрабатывать обычный перевод с пустыми данными calldata.

Контракт, в котором нет функции receive или fallback с атрибутом payable, обычно отклоняет обычные прямые переводы.

Однако контракт не может гарантировать, что его баланс всегда останется нулевым.

В EVM есть специальные способы увеличить баланс контракта, не выполняя его логику receive или fallback.

Внутренний учет контракта не должен исходить из того, что фактический баланс всегда равен сумме, записанной функциями обработки платежей.

Функции fallback и токены ERC-20

Обычный перевод токена ERC-20 не вызывает функцию fallback контракта-получателя.

Контракт токена изменяет балансы в собственном хранилище.

Контракт-получатель может получить баланс токена без выполнения какого-либо кода.

ERC-20 определяет переводы через контракт токена, а не через обязательный обратный вызов получателя.

Контракту не следует полагаться на выполнение функции fallback для обнаружения каждого депозита токенов.

В приложениях обычно используются специальные функции депозита или отдельные правила учета балансов.

Функции fallback и NFT

Некоторые безопасные методы перевода NFT вызывают у контракта-получателя специальную функцию для обработки поступления токена.

Эта функция отличается от общей функции fallback.

Если требуемой функции-получателя нет, вызов может попасть в fallback, поскольку его селектор не распознан.

Разрешающая вызовы функция fallback не должна имитировать поддержку получения NFT, если контракт намеренно не реализует требуемое поведение.

Неправильный ответ может привести к отмене перевода или затруднить возврат актива.

Может ли функция fallback генерировать события?

При получении платежа или неподдерживаемого вызова функция fallback может генерировать события.

В событии можно записать отправителя, сумму перевода, селектор или другое полезное значение.

Эти сведения помогают разработчикам отслеживать интеграции и расследовать неожиданную активность.

Генерация события расходует газ и может завершиться неудачей, если вызывающая сторона предоставила слишком малый лимит.

События в блокчейне общедоступны, поэтому их не следует использовать как конфиденциальные записи.

Полное журналирование calldata также может создавать лишние расходы, поскольку данные транзакции и так доступны для просмотра.

Может ли функция fallback изменять хранилище?

При наличии достаточного количества газа функция fallback может изменять хранилище контракта.

Она может обновлять счетчики, записи о платежах, разрешения, сведения о маршрутизации или другие состояния.

Изменение хранилища увеличивает расход газа и расширяет возможные последствия для безопасности.

Для функции fallback, меняющей важные состояния, необходимы понятный контроль доступа и тщательно протестированные условия.

Обработка платежей не должна зависеть от записи в хранилище, если вызывающая сторона может предоставить только ограниченное количество газа.

Можно ли унаследовать функцию fallback?

Функция fallback может участвовать в наследовании Solidity.

Ее можно объявить как virtual, а затем переопределить в производном контракте.

К ней также можно применять модификаторы.

Наследование может усложнить понимание итогового поведения вызова, если связанные функции реализованы в нескольких контрактах.

Аудиторам следует изучать полную скомпилированную структуру наследования, а не только один исходный файл.

Как тестировать функцию fallback

Разработчикам следует протестировать вызов с неизвестным четырехбайтовым селектором.

Следует протестировать calldata длиной менее четырех байт.

Нужно протестировать пустую calldata без передаваемой криптовалюты.

Нужно протестировать пустую calldata с передаваемой криптовалютой.

Следует проверить непустую нераспознанную calldata с передаваемым значением и без него.

Если в контракте есть функция receive, необходимо проверить различия маршрутизации вызовов.

Для прокси нужно проверить корректную передачу возвращаемых данных и данных об ошибках.

Тесты обновления должны подтвердить сохранность всех существующих данных хранилища.

Тестирование безопасности должно охватывать повторный вход, коллизии селекторов, некорректные данные calldata, несанкционированные обновления и недостаток газа.

Как провести аудит функции fallback

Сначала аудиторам следует определить все типы вызовов, которые могут попасть в функцию fallback.

Затем нужно выяснить, есть ли у функции атрибут payable.

Также следует проверить наличие отдельной функции receive.

Необходимо изучить каждое изменение хранилища, внешний вызов, модификатор, операцию на ассемблере и проверку привилегий.

При аудите прокси необходимо проверить, как выбирается адрес реализации.

Целевой адрес delegatecall не должен изменяться неавторизованным пользователем.

Возвращаемые данные и сведения об отмене операции необходимо передавать точно.

При обновлении реализации следует сохранять совместимость структуры хранилища.

Также нужно изучить администратора, процесс управления, задержку обновления и средства экстренного контроля.

Рекомендации по функциям fallback

По возможности используйте обычные именованные функции для стандартного поведения приложения.

Если контракт намеренно принимает обычные переводы нативной криптовалюты, определите отдельную функцию receive.

Если пользовательская маршрутизация не нужна, отклоняйте неподдерживаемые селекторы.

Сохраняйте простоту обработки платежей в функции fallback.

Считайте любые данные calldata и вызовы ненадежными.

Перед ручным декодированием проверяйте селекторы и длину данных.

Используйте проверенные стандарты прокси вместо непроверенной логики перенаправления.

Защитите ячейки хранилища для реализации, администратора и beacon.

Сохраняйте структуру хранилища при обновлениях.

Установите четкий контроль доступа для каждой функции обновления.

При перенаправлении вызовов точно возвращайте данные об успехе и ошибке.

Используйте безопасный порядок обновления состояния и надлежащую защиту от повторного входа.

Проверяйте необычные вызовы, которые могут никогда не создаваться обычными интерфейсами кошельков.

Используйте актуальную стабильную версию компилятора Solidity и изучайте официальный список известных ошибок компилятора.

Распространенные ошибки при работе с функцией fallback

Одна из распространенных ошибок — предположение, что функция fallback запускается после отмены операции в соответствующей обычной функции.

Еще одна ошибка — добавление атрибута payable без безопасного механизма вывода средств.

Некоторые контракты принимают обычные платежи через fallback, не определяя более понятную функцию receive.

При ручном декодировании calldata иногда не проверяют длину данных.

Вызывающий контракт может принять успешное выполнение fallback за успешное выполнение запрошенной функции.

Адрес реализации в прокси может храниться в ячейке, совпадающей с ячейкой состояния приложения.

При обновлении может измениться порядок переменных, что приведет к повреждению балансов или разрешений.

Неограниченно изменяемый адрес delegatecall может позволить выполнять произвольный код в контексте прокси.

Сложная функция fallback может завершиться ошибкой, если получит меньше газа, чем ожидалось.

Разработчик может ошибочно рассчитывать, что перевод ERC-20 вызовет функцию fallback.

Распространенные заблуждения о функциях fallback

Функция fallback не является универсальным обработчиком ошибок смарт-контракта.

Она не вызывается после каждой неуспешной транзакции.

У нее нет атрибута payable по умолчанию.

Она не всегда подходит для приема обычных платежей в криптовалюте.

В контракте может быть только одна функция fallback.

У функции fallback нет обычного селектора функции.

Она может обрабатывать нераспознанные данные calldata, даже если криптовалюта не переводится.

Успешное выполнение fallback не доказывает, что вызывающая сторона использовала правильный интерфейс контракта.

Функция fallback прокси может предоставить пользователям доступ к коду, который не хранится по адресу прокси.

Проверка исходного кода одного лишь прокси не подтверждает безопасность его текущей реализации.

Часто задаваемые вопросы

Что такое функция fallback в Solidity?

Функция fallback — это специальная внешняя функция, которая обрабатывает вызовы, не соответствующие другим функциям смарт-контракта.

Когда выполняется функция fallback?

Она выполняется, когда ни одна объявленная функция не соответствует переданному селектору, либо когда calldata пуста и функция receive отсутствует.

Может ли в контракте быть несколько функций fallback?

Нет. В контракте Solidity может быть не более одной функции fallback.

Есть ли у функции fallback имя?

Нет. Ее объявляют с помощью ключевого слова fallback, а не обычного имени функции.

Должна ли функция fallback иметь внешнюю видимость?

Да, для функции fallback необходимо указать внешнюю видимость.

Имеет ли функция fallback атрибут payable по умолчанию?

Нет. Она принимает нативную криптовалюту, только если для нее явно указан атрибут payable.

Что происходит, если средства отправлены в функцию fallback без атрибута payable?

Нераспознанный вызов отменяется при попытке перевести ненулевую сумму.

Чем отличаются fallback и receive?

Receive обрабатывает пустые данные calldata, а fallback в первую очередь обрабатывает вызовы, не соответствующие объявленным функциям.

Какая функция обрабатывает обычный перевод криптовалюты?

Если функция receive существует, перевод обрабатывает она. Функция fallback с атрибутом payable делает это только при отсутствии receive.

Запускается ли fallback после сбоя другой функции?

Нет. Сбой внутри функции, которой соответствует вызов, не перенаправляет выполнение в fallback.

Может ли fallback анализировать данные транзакции?

Да, она может получить все данные calldata, переданные вызывающей стороной.

Может ли fallback возвращать данные?

Да. В расширенном варианте она может напрямую возвращать вызывающей стороне необработанные байты.

Зачем прокси-контрактам нужна функция fallback?

Она перенаправляет вызовы пользователей контракту реализации с помощью delegatecall.

Что сохраняет delegatecall?

Он сохраняет исходные адрес отправителя и значение, а код реализации выполняется с использованием хранилища и баланса прокси.

Изменяет ли delegatecall хранилище реализации?

Нет. Код реализации, вызванный через delegatecall, обычно читает и изменяет хранилище вызывающего прокси.

Что такое контракт реализации?

Это контракт, содержащий бизнес-логику, выполняемую через обновляемый прокси.

Что такое коллизия селекторов?

Она возникает, когда разные сигнатуры функций имеют одинаковый четырехбайтовый селектор.

Почему важна структура хранилища?

Несовместимая структура хранилища может привести к тому, что обновленная реализация неверно прочитает или перезапишет существующие данные прокси.

Может ли функция fallback привести к повторному входу?

Да. Если газа достаточно, она может повторно вызвать другой контракт.

Может ли fallback отклонить платеж?

Да. Функция fallback без атрибута payable или функция, явно отменяющая операцию, может отклонить обычный платеж в рамках вызова сообщения.

Может ли контракт предотвратить любое увеличение баланса?

Нет. Некоторые механизмы EVM могут увеличить баланс контракта без выполнения логики receive или fallback.

Вызывает ли перевод ERC-20 функцию fallback?

Обычно нет, поскольку контракт токена обновляет балансы, не вызывая контракт-получатель.

Может ли функция fallback генерировать событие?

Да, если вызову предоставлено достаточно газа для этой операции.

Может ли функция fallback обновлять хранилище?

Да, но обновление хранилища увеличивает расходы и может завершиться неудачей при ограниченном количестве газа.

Можно ли применять к fallback модификаторы?

Да, к функции fallback можно применять модификаторы Solidity.

Можно ли унаследовать fallback?

Да. Ее можно объявить как virtual, а затем переопределить в производном контракте.

Доказывает ли успешный низкоуровневый вызов существование запрошенной функции?

Нет. Неизвестный селектор мог быть принят функцией fallback.

Должен ли каждый смарт-контракт содержать функцию fallback?

Нет. Ее следует определять только в том случае, если контракту нужна специальная обработка нераспознанных вызовов.

Безопасна ли функция fallback в обновляемом контракте?

Она может быть безопасной, если логика перенаправления, структура хранилища, реализация и полномочия на обновление правильно спроектированы и проверены аудитом.

Каков главный риск функции fallback?

Он зависит от ее назначения. Критическую опасность могут представлять делегирование вызовов прокси, неограниченные внешние вызовы, небезопасные обновления и неожиданная обработка платежей.

Заключение

Функция fallback — это специальная точка входа Solidity для внешних вызовов, не соответствующих другим объявленным функциям смарт-контракта.

Если в контракте нет функции receive, она также может обрабатывать вызовы с пустыми данными calldata.

Функция fallback с атрибутом payable может принимать нативную криптовалюту, а функция без этого атрибута отклоняет нераспознанные вызовы, сопровождаемые переводом средств.

Для намеренного приема обычных переводов криптовалюты обычно понятнее использовать функцию receive.

Функции fallback необходимы обновляемым прокси, поскольку с их помощью вызовы перенаправляются контрактам реализации через delegatecall.

Этот процесс сохраняет исходные адрес отправителя и значение, а код реализации выполняется с использованием хранилища прокси.

Маршрутизация вызовов через функцию fallback прокси сопряжена с рисками несовместимости структуры хранилища, коллизий селекторов, полномочий на обновление и delegatecall.

Функции fallback также могут создавать риски повторного входа, отказа в обслуживании, недостатка газа, ошибок декодирования и ошибочной интерпретации успешного вызова.

Разработчикам следует ограничивать функциональность fallback, при необходимости отклонять неподдерживаемые вызовы и использовать обычные именованные функции для стандартной логики приложения.

Понимание функции fallback необходимо для оценки смарт-контрактов в криптовалютной сфере: эта функция без имени может управлять платежами, маршрутизацией прокси, поведением модульных аккаунтов и выполнением целого децентрализованного приложения.