Аудит FatCats
Резюме управления
FatCats связались с Sayfer Security, чтобы провести аудит смарт-контрактов по их контракту NFT в сети Ethereum.
За период исследования в 3 недели мы обнаружили 6 уязвимостей в контракте. Одна уязвимость была классифицирована как высокая, что позволяло злоумышленнику получить доступ к метаданным NFT до того, как они были раскрыты, и сделать интеллектуальные прогнозы об аирдропах или конкретных транзакциях чеканки для редких NFT.
Большинство уязвимостей актуальны только при создании новых NFT, поэтому мы настоятельно рекомендуем исправить уязвимости, обнаруженные в этом отчете, перед созданием новых.
Уязвимости по рискам
критический – Непосредственная или текущая часть бизнеса эксплуатируется с прямыми ключевыми потерями бизнеса.
High – Прямая угроза ключевым бизнес-процессам.
Medium – Косвенная угроза ключевым бизнес-процессам или частичная угроза бизнес-процессам.
Низкий – Прямых угроз нет. Уязвимость может быть использована с использованием других уязвимостей.
Информационный - Этот вывод не указывает на уязвимость, но содержит комментарий, который уведомляет о недостатках дизайна и неправильной реализации, которые могут вызвать проблему в долгосрочной перспективе.
Подход
Введение
FatCats связались с Сейфером, чтобы провести аудит безопасности смарт-контрактов FatCats.
В этом отчете задокументировано исследование, проведенное Sayfer с использованием выбранных ресурсов, определенных в рамках области исследования. В частности, этот отчет отображает обзор уровня безопасности для смарт-контрактов FatCats.
Жизненный цикл нашего проекта по тестированию на проникновение:
Обзор области применения
Технический обзор
Проверка области действия
Модель угрозы
Оценка безопасности
Оценка безопасности
Проверка области действия
Мы начали с того, что убедились, что объем, определенный нам клиентом, был технически логичен.
Решение о том, какой объем подходит для данной системы, является частью начального обсуждения.
Модель угрозы
Мы определили, что самая большая текущая угроза для системы — это возможность злоумышленников украсть средства из контракта. Вторым по величине риском для платформы является возможность атаки с целью кражи NFT из контракта.
Обзор протокола
Введение протокола
Fat Cats — это набор из 5,000 уникальных NFT, которые служат токеном членства и долей всех активов Fat Cats. Владение Fat Cats NFT дает вам доступ к доле всех активов DAO по доступной цене.
Все ликвидные средства будут храниться в корзине стабильных монет и других криптоактивов по усмотрению участников. В случае срочных решений Совет может потратить до 20% всех депонированных средств.
Контракт FatCats — это контракт на токены NFT, чеканка которого осуществляется поэтапно — шаг 1, шаг 2 и публичная чеканка. Шаги минтинга устанавливаются владельцем. Пользователи из белого списка могут создавать NFT на шаге 1 и шаге 2. Пользователи из белого списка проверяются доказательством Меркла.
Контракт FatCats наследует MerkleProof, Ownable, Address, VRFCoordinatorV2Interface, VRFConsumerBaseV2, IERC721Receiver, Context, IERC721Metadata, Strings, ERC165, IERC721, стандартные смарт-контракты из библиотеки OpenZeppelin. Эти контракты OpenZeppelin считаются проверенными сообществом и проверенными временем, и, следовательно, не входят в область аудита.
График протокола
Оценка безопасности
Следующие тестовые случаи были руководством при аудите системы. Этот контрольный список представляет собой модифицированную версию СКСВС v1.2, с улучшенной грамматикой, ясностью, краткостью и дополнительными критериями. В случае пробела в нумерации исходный критерий был удален. Критерии, отмеченные звездочкой, добавлены нами.
Архитектура, дизайн и моделирование угроз
| Архитектура, дизайн и моделирование угроз | Название теста |
| G1.2 | Каждому вносимому изменению конструкции предшествует моделирование угроз. |
| G1.3 | Документация четко и точно определяет все границы доверия в контракте (доверительные отношения с другими контрактами и значимыми потоками данных). |
| G1.4 | SCSVS, требования безопасности или политика доступны для всех разработчиков и тестировщиков. |
| G1.5 | Определены события для операций (изменение состояния/критические для бизнеса). |
| G1.6 | Проект включает в себя механизм, который может временно остановить важные функции в случае атаки. Этот механизм не должен блокировать доступ пользователей к их активам (например, токенам). |
| G1.7 | Количество неиспользованных криптовалют, хранящихся в контракте, контролируется и находится на минимально допустимом уровне, чтобы не стать потенциальной целью атаки. |
| G1.8 | Если резервную функцию может вызвать кто угодно, она включается в модель угроз. |
| G1.9 | Бизнес-логика последовательна. Важные изменения в логике должны применяться во всех контрактах. |
| G1.10 | Для обнаружения уязвимостей используются инструменты автоматического анализа кода. |
| G1.11 | Используется последняя основная версия Solidity. |
| G1.12 | При использовании внешней реализации контракта используется самая последняя версия. |
| G1.13 | Когда функции переопределяются для расширения функциональности, ключевое слово super используется для сохранения предыдущей функциональности. |
| G1.14 | Порядок наследования тщательно определен. |
| G1.15 | Есть компонент, который отслеживает активность контракта с помощью событий. |
| G1.16 | Модель угроз включает в себя китовые транзакции. |
| G1.17 | Утечка одного приватного ключа не ставит под угрозу безопасность всего проекта. |
Политика и процедуры
| Политика и процедуры | Название теста |
| G2.2 | Безопасность системы находится под постоянным контролем (например, ожидаемый уровень средств). |
| G2.3 | Существует политика отслеживания новых уязвимостей в системе безопасности и обновления библиотек до последней защищенной версии. |
| G2.4 | С отделом безопасности можно связаться публично, и процедура обработки сообщений об ошибках (например, тщательное вознаграждение за обнаружение ошибок) четко определена. |
| G2.5 | Процесс добавления новых компонентов в систему четко определен. |
| G2.6 | Процесс крупных системных изменений включает моделирование угроз сторонней компанией. |
| G2.7 | Процесс добавления и обновления компонентов системы включает в себя аудит безопасности внешней компанией. |
| G2.8 | В случае взлома существует четкая и хорошо известная процедура смягчения последствий. |
| G2.9 | Процедура в случае взлома четко определяет, какие лица должны выполнять требуемые действия. |
| G2.10 | Процедура включает оповещение других проектов о взломе по доверенным каналам. |
| G2.11 | Определена процедура предотвращения утечки закрытого ключа. |
Возможность обновления
| Возможность обновления | Название теста |
| G3.2 | Перед обновлением делается эмуляция в форке основной сети и на локальной копии все работает как положено. |
| G3.3 | Процесс обновления выполняется с помощью мультиподписного контракта, в котором операцию должны одобрить несколько человек. |
| G3.4 | Временные блокировки используются для важных операций, чтобы у пользователей было время наблюдать за предстоящими изменениями (обратите внимание, что устранение потенциальных уязвимостей в этом случае может быть более сложным). |
| G3.5 | инициализировать () можно вызвать только один раз. |
| G3.6 | инициализировать () может вызываться только авторизованной ролью через соответствующие модификаторы (например, инициализатор, только владелец). |
| G3.7 | Процесс обновления выполняется в одной транзакции, поэтому никто не может запустить его заранее. |
| G3.8 | В обновляемых контрактах зарезервированы пробелы в слотах, чтобы предотвратить перезапись. |
| G3.9 | Количество зарезервированных (в качестве промежутка) слотов было уменьшено соответствующим образом, если были добавлены новые переменные. |
| G3.10 | Порядок объявления переменных состояния контракта и их типы не изменились. |
| G3.11 | Новые значения, возвращаемые функциями, такие же, как и в предыдущих версиях контракта (например, владелец (), баланс (адрес)). |
| G3.12 | Реализация инициализирована. |
| G3.13 | Реализация не может быть уничтожена. |
Бизнес-логика
| Бизнес-логика | Название теста |
| G4.2 | Реализация логики контракта и параметров протокола соответствует документации. |
| G4.3 | Бизнес-логика выполняется в последовательном порядке шагов, и невозможно пропустить шаги или выполнить их в порядке, отличном от запланированного. |
| G4.4 | В договоре правильно установлены бизнес-лимиты. |
| G4.5 | Бизнес-логика не полагается на значения, полученные из ненадежных контрактов (особенно при наличии нескольких вызовов одного и того же контракта в одном потоке). |
| G4.6 | Бизнес-логика не зависит от баланса контракта (например, баланс == 0). |
| G4.7 | Конфиденциальные операции не зависят от данных блока (например, хэш блока, метка времени). |
| G4.8 | Контракт использует механизмы, которые смягчают атаки упорядочения транзакций (упреждающие) (например, схемы предварительной фиксации). |
| G4.9 | Контракт не отправляет средства автоматически, а вместо этого позволяет пользователям снимать средства отдельными транзакциями. |
Контроль доступа
| Контроль доступа | Название теста |
| G5.2 | Соблюдается принцип наименьших привилегий. Другие контракты должны иметь доступ только к функциям и данным, для которых у них есть специальное разрешение. |
| G5.3 | Новые контракты с доступом к проверенному контракту по умолчанию придерживаются принципа минимальных прав. Контракты должны иметь минимальные разрешения или вообще не иметь их до тех пор, пока доступ к новым функциям не будет предоставлен явным образом. |
| G5.4 | Создатель контракта соблюдает принцип наименьших привилегий, и его права строго следуют изложенным в документации. |
| G5.5 | Контракт применяет правила контроля доступа, указанные в доверенном контракте, особенно если присутствует контроль доступа на стороне клиента dApp, который можно обойти. |
| G5.6 | Вызовы внешних контрактов разрешены только в случае необходимости. |
| G5.7 | Код модификатора понятен и прост. Логика не должна содержать внешних вызовов недоверенных контрактов. |
| G5.8 | Все атрибуты пользователей и данных, используемые элементами управления доступом, хранятся в доверенных контрактах, и другие контракты не могут ими манипулировать, если только это не разрешено специально. |
| G5.9 | Элементы управления доступом дают сбой безопасно, в том числе при возврате. |
| G5.10 | Если входные данные (параметры функции) проверены, по возможности используется метод положительной проверки (внесение в белый список). |
Связь
| Связь | Название теста |
| G6.2 | Выявляются библиотеки, которые не являются частью приложения (но от которых зависит работа смарт-контракта). |
| G6.3 | Вызов делегата не используется с недоверенными контрактами. |
| G6.4 | Контракты с третьими сторонами не затмевают специальные функции (например, возврат). |
| G6.5 | Контракт не проверяет, является ли адрес контрактом, используя код операции extcodesize. |
| G6.6 | Атаки с повторным входом смягчаются путем блокировки рекурсивных вызовов из других контрактов и следования шаблону Check-Effects-Interactions. Не используйте функцию отправки, если это не является обязательным. |
| G6.7 | Результат низкоуровневых вызовов функций (например, отправить, делегировать вызов, позвонить) из других договоров проверяется. |
| G6.8 | Контракт основывается на данных, предоставленных правильным отправителем, и не зависит от значения tx.origin. |
Арифметический
| Арифметический | Название теста |
| G7.2 | Значения и математические операции устойчивы к целочисленным переполнениям. Используйте библиотеку SafeMath для арифметических операций до Solidity 0.8.*. |
| G7.3 | Непроверенные фрагменты кода из Solidity ≥ 0.8.* не вводят целочисленное недополнение/переполнение. |
| G7.4 | Экстремальные значения (например, максимальные и минимальные значения типа переменной) учитываются и не меняют логическую схему контракта. |
| G7.5 | Нестрогое неравенство используется для балансового равенства. |
| G7.6 | В расчетах используются правильные порядки величин. |
| G7.7 | В расчетах умножение выполняется перед делением для точности. |
| G7.8 | Контракт не предполагает точности с фиксированной точкой и использует множитель или сохраняет как числитель, так и знаменатель. |
Отказ в обслуживании
| Отказ в обслуживании | Название теста |
| G8.2 | Контракт не повторяется по несвязанным циклам. |
| G8.3 | Функция самоуничтожения используется только в случае необходимости. Если это включено в контракт, это должно быть четко описано в документации. |
| G8.4 | Бизнес-логика не блокируется, если субъект (например, контракт, учетная запись, оракул) отсутствует. |
| G8.5 | Бизнес-логика не мешает пользователям использовать контракты (например, стоимость транзакции выше, чем прибыль). |
| G8.6 | Выражения функций assert или require имеют проходной вариант. |
| G8.7 | Если резервную функцию никто не вызывает, она не блокирует функции контракта. |
| G8.8 | В цикле нет затратных операций. |
| G8.9 | В цикле нет обращений к недоверенным контрактам. |
| G8.10 | Если есть возможность приостановить действие договора, возможно и его возобновление. |
| G8.11 | Если используются белые и черные списки, они не мешают нормальной работе системы. |
| G8.12 | Отсутствует DoS, вызванный переполнением и недополнением. |
Данные блокчейна
| Данные блокчейна | Название теста |
| G9.2 | Любые сохраненные данные в контрактах не считаются безопасными или частными (даже частные переменные). |
| G9.3 | В блокчейне не хранятся конфиденциальные данные (пароли, персональные данные, токены и т. д.). |
| G9.4 | Контракты не используют строковые литералы в качестве ключей для отображений. Вместо этого используются глобальные константы для предотвращения атаки Homoglyph. |
| G9.5 | Контракт не тривиально генерирует псевдослучайные числа на основе информации из блокчейна (например, заполнение номером блока). |
Использование газа и ограничения
| Использование газа и ограничения | Название теста |
| G10.1 | Использование газа предполагается, определяется и имеет четкие ограничения, которые нельзя превышать. Ни структура кода, ни злонамеренный ввод не должны вызывать газового истощения. |
| G10.2 | Выполнение функций и функциональность не зависят от жестко запрограммированных сборов за газ (они могут меняться). |
Ясность и читабельность
| Ясность и читабельность | Название теста |
| G11.2 | Логика понятна и разделена на несколько простых контрактов и функций. |
| G11.3 | Каждый контракт имеет короткий комментарий из 1-2 предложений, объясняющий его назначение и функциональность. |
| G11.4 | Используются готовые реализации, это поясняется в комментарии. Если эти реализации были изменены, изменения отмечаются по всему контракту. |
| G11.5 | Порядок наследования учитывается в контрактах, использующих множественное наследование и теневые функции. |
| G11.6 | Там, где это возможно, контракты используют существующий проверенный код (например, контракты токенов или такие механизмы, как принадлежащий) вместо реализации своих собственных. |
| G11.7 | Последовательные шаблоны именования соблюдаются на протяжении всего проекта. |
| G11.8 | Переменные имеют отличительные имена. |
| G11.9 | Все переменные хранения инициализируются. |
| G11.10 | Функции с указанным типом возвращаемого значения возвращают значение этого типа. |
| G11.11 | Используются все функции и переменные. |
| G11.12 | требовать используется вместо возвращаться in if заявления. |
| G11.13 | Ассоциация утверждать используется для проверки внутренних ошибок и требовать Функция используется для обеспечения действительного условия ввода от пользователей и внешних контрактов. |
| G11.14 | Ассемблерный код используется только в случае необходимости. |
Покрытие тестов
| Покрытие тестов | Название теста |
| G12.2 | Нарративы злоупотреблений, подробно описанные в модели угроз, покрываются модульными тестами. |
| G12.3 | Чувствительные функции в проверенных контрактах покрываются тестами на этапе разработки. |
| G12.4 | Реализация проверенных контрактов была проверена на наличие уязвимостей безопасности с использованием как статического, так и динамического анализа. |
| G12.5 | Спецификация контракта была официально проверена |
| G12.6 | Спецификация и результаты формальной проверки включены в документацию. |
Децентрализованные финансы
| Децентрализованные финансы | Название теста |
| G13.1 | Договор кредитора не предполагает изменения его баланса (используемого для подтверждения погашения кредита) только со своими собственными функциями. |
| G13.2 | Функции, которые изменяют баланс кредиторов и/или предоставляют криптовалюту, не подлежат повторному входу, если смарт-контракт позволяет заимствовать криптовалюту основной платформы (например, Ethereum). Он блокирует атаки, которые обновляют баланс заемщика во время оформления срочного кредита. |
| G13.3 | Функции быстрой ссуды могут вызывать только предопределенные функции в контракте-получателе. Если возможно, определите доверенное подмножество вызываемых контрактов. Обычно отзывается контракт на отправку (заимствование). |
| G13.4 | Если он включает потенциально опасные операции (например, отправка большего количества ETH/токенов, чем заимствовано), функция получателя, которая обрабатывает заимствованные ETH или токены, может быть вызвана только пулом и в рамках процесса, инициированного владельцем принимающего контракта или другим доверенным источником (например, мультиподпись). |
| G13.5 | Расчеты доли пула ликвидности выполняются с максимально возможной точностью (например, если вклад рассчитывается для ETH, это должно быть сделано с точностью до 18 знаков — для Wei, а не для Ether). Делимое должно быть умножено на 10 в степени количества десятичных цифр (например, делимое * 10^18 / делитель). |
| G13.6 | Вознаграждения не могут быть рассчитаны и распределены в рамках того же вызова функции, который вносит токены (он также должен быть определен как невозвратный). Это защищает от сиюминутных колебаний акций. |
| G13.7 | Контракты на управление защищены от атак мгновенных кредитов. Одним из возможных методов смягчения последствий является требование процесса депонирования токенов управления и предложения изменений для выполнения в разных транзакциях, включенных в разные блоки. |
| G13.8 | При использовании оракулов в сети контракты могут приостанавливать операции на основе результатов оракулов (в случае взлома оракула). |
| G13.9 | Внешние контракты (даже доверенные), которым разрешено изменять атрибуты контракта проекта (например, цену токена), имеют следующие ограничения: пороги для изменения (например, не более/менее 5%) и лимит обновлений (например, одно обновление в день). |
| G13.10 | Атрибуты контракта, которые могут обновляться внешними контрактами (даже доверенными), отслеживаются (например, с помощью событий) и реализуется процедура реагирования на инциденты (например, во время продолжающейся атаки). |
| G13.11 | Сложные математические операции, состоящие из операций умножения и деления, сначала выполняют умножение, а затем деление. |
| G13.12 | При расчете биржевых цен (например, ETH в токен или наоборот) числитель и знаменатель умножаются на резервы (см. получитьInputPrice функции в UniswapExchange договор). |
Заказать аудит у Sayfer
Выводы аудита
Угадываемые URI токена
| Статус: | Откройте |
| Снижение | критический |
| Адрес | FatCats.sol |
| Инструменты | Ручное тестирование |
Описание
Имея начальное знание метаданных NFT, злоумышленник может узнать, какой NFT он должен создать, прежде чем он станет общедоступным. Это потенциально может позволить злоумышленнику получить контроль над наиболее ценными NFT в проекте.
Следующая уязвимость позволяет злоумышленнику решить, какой NFT купить, на основе метаданных до публичного раскрытия. Эту уязвимость относительно легко использовать из-за других обнаруженных нами уязвимостей. Во время между shuffle флаг становится правдой в requestRandomWords() и NFT, раскрываемые в revealNFT(), злоумышленник может угадать URI токена.
Если revealed флаг по-прежнему ложный tokenURI() Возвращает hideUri, что означает, что средний пользователь увидит только фиктивный/скрытый URI без полных метаданных.
Чтобы полностью построить строку URI токена, выполняется другая транзакция для выполнения requestRandomWords() метод, который устанавливает s_randomWords с помощью fulfillRandomWords(). Это делается через VRF от Chianlink.
Только тогда выполняется следующий код, который возвращает полную строку URI токена:
Уязвимость в том, что baseURI, maxSupply и s_randomWords являются общедоступными, и злоумышленник может предсказать URI токена без необходимости revealed переменная. В V1 проекта мы видели, что первая выполняемая транзакция requestRandomWords():
А затем вторая транзакция, которая раскрывает NFT, выполняя revealNFT():
Мы видим, что в течение 3 часов злоумышленник мог просматривать любые метаданные NFT до того, как они были раскрыты, и делать умные прогнозы об аирдропах или конкретных транзакциях минтинга для редких NFT.
риска
Выявление NFT не подходит для всех. Это сильно зависит от стратегии и пользовательского опыта, который должен иметь конечный пользователь.
Для большей безопасности мы рекомендуем раскрыть, установить базовый URI и изменить состояние s_randomWords переменная состояния с наименьшей разницей во времени между ними. Хотя уязвимость не устраняется полностью, сокращение времени между этими действиями может снизить риск ее использования злоумышленниками.
Лучшим способом является выполнение всех изменений состояния в одной и той же транзакции при раскрытии, во многих случаях это технически невозможно.
Для более глубокого понимания того, как реализовать случайный аирдроп NFT и более безопасные способы, мы рекомендуем прочитать Стратегии рандомизации для выпадения NFT.
Адреса из белого списка могут быть контрактами
| Статус: | Откройте |
| Снижение | High |
| Адрес | FatCats.sol |
| Инструменты | Ручное тестирование |
Описание
При чеканке NFT контракт на чеканку может блокировать или разрешать чеканку по контрактным адресам. Разрешение чеканки контрактов или наличие уязвимости, позволяющей чеканить контракты, может привести к ситуации, когда злоумышленник может отменить транзакцию, если он заранее знает, какой NFT он должен чеканить.
Модификатор isAUser() используется только для publicMint().
Что касается mintStep1() и mintStep2() методы isWhitelisted() используется модификатор.
Это означает, что код не проверяет неконтрактные адреса в хэшах доказательства Merkle из белого списка.
Хотя мы не можем знать, какие процессы стояли за созданием белого списка и насколько он защищен, сам код уязвим для этой атаки. Проверка неконтрактных адресов вне цепочки или вне той же транзакции не рекомендуется, поскольку она уязвима для нескольких векторов атак.
Злоумышленник может получить NFT и отменить транзакцию, если NFT недостаточно редок. В сочетании с URI угадываемого токена злоумышленник может легко получить предварительную информацию о метаданных NFT и отменить транзакции на основе редкости.
риска
Добавьте isAUser модификатор к mintStep1() и mintStep2() методы.
Слабая небезопасная случайная реализация VRF Chainlink
| Статус: | Откройте |
| Снижение | High |
| Адрес | FatCats.sol |
| Инструменты | Ручное тестирование |
Описание
Ошибки небезопасной случайности возникают, когда функция, которая может выдавать предсказуемые значения, используется в качестве источника случайности в контексте, чувствительном к безопасности.
Смарт-контракты должны полагаться на автономные решения для генерации защищенных случайных чисел. Fatcats использует систему VRF Chainlink для генерации случайного числа, которое позже используется в качестве случайного идентификатора для URI токена с использованием fulfillRandomWords Метод:
Метод сохраняет случайное число в переменной состояния, называемой s_randomWords что по названию подразумевает, что это случайное слово. На практике число определяется по модулю с maxSupply(5000), так что это псевдослабое случайное число в диапазоне от 1 до 5000. Это может привести разработчиков к мысли, что они могут полагаться на это число для гарантированной случайности, а это не так.
риска
Назначьте возвращаемое значение, поступающее из VRF, глобальной переменной состояния.
Централизация контракта и кошелька команды
| Статус: | Откройте |
| Снижение | High |
| Адрес | FatCats.sol |
| Инструменты | Ручное тестирование |
Описание
Проекты, которые полагаются на один ключ, уязвимы к потере ключей, фишинговым атакам, манипуляциям внутренних субъектов, смерти владельца и многому другому.
Когда проект зависит только от одного ключа. Эти виды атак являются наиболее распространенными среди самых крупных взломов.
Проект проверяет isOwner в нескольких местах. Потеря ключей к этому адресу развертывания поставит под угрозу весь проект.
Кроме того, командный кошелек, который будет получать eth с помощью withdraw функция также подвергается тому же вектору атаки
Если вышеуказанные кошельки используют мультиподпись, эта проблема будет решена.
риска
В зависимости от варианта использования, уровня безопасности и пользовательского опыта, который проект хочет применить, существует несколько способов смягчения этой атаки, например, использование кошелька с мультиподписью, умного кошелька или применение нескольких владельцев к проекту.
Функция openPublicBurn переключается, а не открывается
| Статус: | Откройте |
| Снижение | Низкий |
| Адрес | FatCats.sol |
| Инструменты | Ручное тестирование |
Описание
Способ openPublicBurn не просто открывает публичный прожиг, он включает и выключает его в зависимости от текущего состояния переменной.
Это может привести к тому, что разработчик или оператор проекта решит, что они открывают стадию общедоступной записи, но на самом деле отключают ее, что ухудшает репутацию проекта.
риска
Установите переменную состояния publicBurnFlag на true или измените имя метода на
switchPublicBurn.
Пошаговый механизм сложно поддерживать
| Статус: | Откройте |
| Снижение | Инфо |
| Адрес | FatCats.sol |
| Инструменты | Ручное тестирование |
Описание
Код использует логические переменные для каждого шага, это означает, что каждый раз, когда разработчик добавляет еще один шаг, он/она должен добавить логику для переключения сброса флагов. Это может привести к путанице и потенциальным ошибкам безопасности.
Лучшим подходом было бы использовать enum в качестве текущего шага, если это дает преимущества четкого имени шага, такого как EARLY_ADAPTERS, PUBLINK_MINTИ т.д.
Если это слишком многословно или запутанно, его можно реализовать с помощью простого целого числа, это имеет математическое преимущество if step > 2 or require(newStep < oldStep, “can not go back”.
риска
Используйте встроенное перечисление Solidity или простой целочисленный синтаксис.