Ну, что же, сегодня разберем еще пару пунктов из репо.
3. Always check the return value of send. Send fails if call stack depth is at 1024 (can be forced by the caller).
Интересный пункт по нескольким причинам: тут описан и самый популярный баг, и работа с памятью и возможная атака на ваш смарт контракт. Но давайте по порядку.
Always check the return value of send => всегда проверяйте успешность вызова транзакции отправки. Тут может быть и send(), и transfer(), и transferFrom(), и низкоуровневый call(). Хотя тут есть свои некоторые нюансы.
Если мы говорим об отправке Эфира, то проверять возвращаемые значения через bool можно в функциях send() и call(), так как сам transfer() ревертится в случае неудавшейся отправки (там можно ловить ошибку немного по другому, но об этом в следующий раз).
Если же говорим о токенах, то и в transfer()/transferFrom() также необходимо проверять возвращаемый bool. А зачем?
Ну, самая очевидная причина - чтобы не потерять активы. Есть достаточно много случаев, когда после отправки токенов или Эфира в другом контракте происходят какие-либо действия, которые могут помешать получению средств. При этом у вас с контракта все уйдет, а в пункт назначения - нет. В итоге, деньги "потеряются" и вернуть вы их вряд ли сможете.
В целом, нужно просто запомнить, что при любой пересылке активов необходимо проверять его успешность.
Send fails if call stack depth is at 1024 (can be forced by the caller).
Тут нужно знать как работает память в Solidity и EVM. Грубо говоря, есть некая область памяти под названием stack.
Представьте себе, что на столе стоят тарелки сложенные друг на друга.
тарелка - 1
тарелка - 2
тарелка - 3
тарелка - 4
тарелка - 5
Stack работает так, что можно использовать только самые верхние "тарелки" для каких-либо действий. Для того чтjбы наполнить "пятую тарелку", нам нужно переместить ее в начало. Или же, более реальный пример, чтобы сложить значения, которые лежать в "тарелках" 3 и 4, мы должны каждую из них переместить по отдельности в самый верх и уже потом выполнить действие сложения.
P.S. Более опытные разработчики, имеющие дело с памятью, можете поправить меня, если я где-то сказал не так.
Так вот "тарелки" на языке EVM называются слотами. При вызове в другой контракт, в транзакции может быть использовано всего 1024 таких слотов в памяти stack. Если по каким-то причинам, например, из-за не правильной рекурсии в функциях, потребуется больше 1024 слотов, то транзакция обвалится.
Я не помню уже были ли это какой-то протокол или просто задача, но суть была в том, что контракт выдавал флеш займы. Пользователь заходил на проект, кликал по функции, брал займ, как-то использовал его и, в итоге, возвращал на контракт.
При этом в контракте не проверялась успешность возврата займа на сам контракт. Это могло привести к тому, что пользователь брал займ, "загонял" в функцию, которая превышала лимиты в памяти, расходовала весь газ и тихо обваливались, оставляя займ пользователю.
В заключении поста, можно сделать простой вывод: всегда проверяйте успешность пересылки активов!
#transfer #send #call #bool