Вообще с delegatecall есть несколько нюансов использования, которые достаточны трудны для понимания не только новичков, но опытных разработчиков.
Одна из причин того, что такие контракты могут быть взломаны, если устанавливаемые переменные идут не по порядку в обоих контрактах.
Дело в том, что в случае с delegatecall переменные, устанавливаемые в начале контракта, выступают в некоторой роли слотов памяти. И их порядок играет крайне важную роль в корректной работе самого смарт-контракта.
Про это лучше посмотреть в уроке, начиная с 17 минуты, так как текстом это сложно описать.
#delegatecall #hack
Одна из причин того, что такие контракты могут быть взломаны, если устанавливаемые переменные идут не по порядку в обоих контрактах.
Дело в том, что в случае с delegatecall переменные, устанавливаемые в начале контракта, выступают в некоторой роли слотов памяти. И их порядок играет крайне важную роль в корректной работе самого смарт-контракта.
Про это лучше посмотреть в уроке, начиная с 17 минуты, так как текстом это сложно описать.
#delegatecall #hack
👍1🔥1
Подготовка смарт контракта к аудиту
Я нашел прекрасную ветку твитов от человека, который регулярно работает с проверками смарт контрактов. Тут он описывает рекомендации, которыми должен пользоваться каждый уважающий себя разработчик. Предлагаю перевод:
1. Делайте подробные комментарии к своему коду так, чтобы другой человек, который будет проводить аудит, смог сразу понять, что делает данный код и зачем он нужен в контракте вообще.
2. Документируйте все, что является публичным API контракта.
3. Большой плюс, если вы будете использовать NatSpec формат (о нем подробнее в следующих постах).
4. Перед аудитом пропишите тесты каждой функции, require, event и т.д. Хороший инструмент для таких целей npm пакет solidity-coverage (входит в hardhat toolbox по умолчанию).
5. Избавьтесь от всех ошибок в контракте для его успешной компиляции.
6. Не старайтесь переоптимизировать свой код. Порой критические ошибки появляются именно там. При оптимизации пишите комментарий о том, для чего это делается в этом конкретном случае.
7. Используйте понятные переменные и названия функций. Сокращения, абстракции или символика не сделают ваш код лучше.
8. Удаляйте старые комментарии, неиспользуемый код и функции.
9. Не изобретайте велосипед там, где это не нужно. Есть прекрасные библиотеки для создания токенов, математических операций и многого другого. Безопаснее использовать проверенные методы, чем "городить" свои.
10. Не делайте изменения в коде (комите на GitHub) во время аудита кода. Это сильно усложняет работу.
11. Если вы сможете сами рассказать про свой код на созвоне или лично, это сильно поможет проверяющему.
12. В комментариях аудитору опишите свои планы, как вы планируете использовать свои контракт в будущем: обновлять, дополнять, наследовать и т.д.
13. Оставайтесь на связи! Даже с учетом подробной документации, у проверяющих всегда могут найтись дополнительные вопросы.
14. Не надейтесь, что аудит кода на 100% убережет вас от взлома. Это лишь еще одна ступень безопасности!
Если обобщать все твиты в одно предложение, то оно будет звучать так: пишите понятный код с подробными комментариями и уважайте работу проверяющих.
#аудит #безопасность #взлом #hack
Я нашел прекрасную ветку твитов от человека, который регулярно работает с проверками смарт контрактов. Тут он описывает рекомендации, которыми должен пользоваться каждый уважающий себя разработчик. Предлагаю перевод:
1. Делайте подробные комментарии к своему коду так, чтобы другой человек, который будет проводить аудит, смог сразу понять, что делает данный код и зачем он нужен в контракте вообще.
2. Документируйте все, что является публичным API контракта.
3. Большой плюс, если вы будете использовать NatSpec формат (о нем подробнее в следующих постах).
4. Перед аудитом пропишите тесты каждой функции, require, event и т.д. Хороший инструмент для таких целей npm пакет solidity-coverage (входит в hardhat toolbox по умолчанию).
5. Избавьтесь от всех ошибок в контракте для его успешной компиляции.
6. Не старайтесь переоптимизировать свой код. Порой критические ошибки появляются именно там. При оптимизации пишите комментарий о том, для чего это делается в этом конкретном случае.
7. Используйте понятные переменные и названия функций. Сокращения, абстракции или символика не сделают ваш код лучше.
8. Удаляйте старые комментарии, неиспользуемый код и функции.
9. Не изобретайте велосипед там, где это не нужно. Есть прекрасные библиотеки для создания токенов, математических операций и многого другого. Безопаснее использовать проверенные методы, чем "городить" свои.
10. Не делайте изменения в коде (комите на GitHub) во время аудита кода. Это сильно усложняет работу.
11. Если вы сможете сами рассказать про свой код на созвоне или лично, это сильно поможет проверяющему.
12. В комментариях аудитору опишите свои планы, как вы планируете использовать свои контракт в будущем: обновлять, дополнять, наследовать и т.д.
13. Оставайтесь на связи! Даже с учетом подробной документации, у проверяющих всегда могут найтись дополнительные вопросы.
14. Не надейтесь, что аудит кода на 100% убережет вас от взлома. Это лишь еще одна ступень безопасности!
Если обобщать все твиты в одно предложение, то оно будет звучать так: пишите понятный код с подробными комментариями и уважайте работу проверяющих.
#аудит #безопасность #взлом #hack
👍1