Обновления и патчи Openzeppelin
В разделе Security в репо Openzeppeling можно найти информацию о проблемах в старых версиях контрактов и версии патчей, когда эти уязвимости были поправлены.
Это может помочь при аудите других контрактов, когда вы захотите проверить, какие версии используются и есть ли среди них устаревшие.
#openzeppelin
В разделе Security в репо Openzeppeling можно найти информацию о проблемах в старых версиях контрактов и версии патчей, когда эти уязвимости были поправлены.
Это может помочь при аудите других контрактов, когда вы захотите проверить, какие версии используются и есть ли среди них устаревшие.
#openzeppelin
Больше о побитовых операциях
На днях в одном из конкурсных аудитов встретил следующий код:
function hasBeenDistributed(uint256 _index) public view returns (bool) {
uint256 distributedWordIndex = _index / 256;
uint256 distributedBitIndex = _index % 256;
uint256 distributedWord = distributedBitMap[distributedWordIndex];
uint256 mask = (1 << distributedBitIndex);
return distributedWord & mask == mask;
}
и немного опешил от подобной реализации. Прежде я не встречал такого в контрактах, поэтому пришлось спрашивать в чатах и искать дополнительную информации в сети.
Если для вас предельно понятны функции в тестовом примере и на скрине поста, то, поздравляю, с побитовыми операциями у вас все в порядке. Если же нет, то следующие три статьи прольют больше света на этот вопрос.
Статьи на английском языке, но время на них стоит потратить, чтобы хорошо разобраться.
Во-первых, читаем эту статью на Медиум.
Потом читаем пост с Solidity Developer. Спасибо @SovaSlava, что показал мне ее.
И в конце, получаем небольшой разбор с операциями со скрина.
Надеюсь, после этого вам, как и мне, станет более понятна логики таких действий.
#bitmap #bit
На днях в одном из конкурсных аудитов встретил следующий код:
function hasBeenDistributed(uint256 _index) public view returns (bool) {
uint256 distributedWordIndex = _index / 256;
uint256 distributedBitIndex = _index % 256;
uint256 distributedWord = distributedBitMap[distributedWordIndex];
uint256 mask = (1 << distributedBitIndex);
return distributedWord & mask == mask;
}
и немного опешил от подобной реализации. Прежде я не встречал такого в контрактах, поэтому пришлось спрашивать в чатах и искать дополнительную информации в сети.
Если для вас предельно понятны функции в тестовом примере и на скрине поста, то, поздравляю, с побитовыми операциями у вас все в порядке. Если же нет, то следующие три статьи прольют больше света на этот вопрос.
Статьи на английском языке, но время на них стоит потратить, чтобы хорошо разобраться.
Во-первых, читаем эту статью на Медиум.
Потом читаем пост с Solidity Developer. Спасибо @SovaSlava, что показал мне ее.
И в конце, получаем небольшой разбор с операциями со скрина.
Надеюсь, после этого вам, как и мне, станет более понятна логики таких действий.
#bitmap #bit
👍8
Интервью с Zach Obront
Недавно вышло интервью с Заком, тем самым аудитором, который вместе с Trust нашел крутой критический баг в сети Optimism.
Мне нравятся подобные истории, так как они показывают, сколько времени человек потратил на свой путь, а также порой можно услышать дельные советы.
В данном интервью больше всего мне понравилось то, как он учился делать аудит и как проводил работу над ошибками. Учитывая то, что он является одним из топовых аудиторов, послушать нужно всем.
Смотрим видео и вдохновляемся!
Приятного просмотра.
#obront
Недавно вышло интервью с Заком, тем самым аудитором, который вместе с Trust нашел крутой критический баг в сети Optimism.
Мне нравятся подобные истории, так как они показывают, сколько времени человек потратил на свой путь, а также порой можно услышать дельные советы.
В данном интервью больше всего мне понравилось то, как он учился делать аудит и как проводил работу над ошибками. Учитывая то, что он является одним из топовых аудиторов, послушать нужно всем.
Смотрим видео и вдохновляемся!
Приятного просмотра.
#obront
👍6🔥2
Not So-Famous Solidity Attack Vectors
Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.
Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.
Тем не менее, видео достойное для изучения.
#security #ethdubai
Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.
Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.
Тем не менее, видео достойное для изучения.
#security #ethdubai
YouTube
Not So-Famous Solidity Attack Vectors, often missed/overlooked while Auditing! by Tejaswa Rastogi
Get notified when tickets, dates and call for speakers are available for our next edition in 2024 https://www.ethdubaiconf.org/api/next
👍6
5 стадий обучения аудитора
Постов на канале сейчас выходит очень мало, так как я с головой ушел в практику аудита. Конкурс за конкурсом с начала марта. Пока хвастаться нечем, но хочу поделиться свои новым видением про обучение.
Во-первых, web3 разработчик и web3 аудитор, хоть и оперируют одинаковыми знаниями, все таки разные профессии. Проблемы с безопасностью могут быть даже в самом крутом коде, написанным сеньорами с огромный опытом. При этом даже очень опытный аудитор, возможно, также не сможет написать достойный код, решающий определенную задачу, как это сделает человек, который сфокусирован на разработке.
Поэтому тут я скорее за разделение профессий. Фокус на чем-то одном, будет быстрее продвигать вас в обучении.
Во-вторых, для себя я определил 5 глобальных стадий обучения аудитора.
1. Обучение базовым уязвимостям в смарт контрактах. Тут будет достаточно получить понимание, чем реентранси отличается от dos атак. Ну, и знать, как их искать в коде. Для этого вообще не обязательно записываться на онлайн курсы. Вся информация есть на этом канале и в сети, на первых страницах гугла.
2. Решение задач. Ethernaut, dvd, CTE и любые другие задачи будут невероятно качественным подспорьем на этой стадии. Тут для аудитора важно будет начать определять участки кода с возможной проблемой и находить варианты взлома.
3. Аудиторские отчеты. Только после того, как вы научитесь решать задачи, стоит преступать к чтению отчетов. Можно брать отчеты с популярных площадок, типа c4, или от профессиональных аудиторов, типа obront. На этом этапе нужно понять, что уязвимости в контрактах выходят за рамки обычных задача. Будет не лишним и самому повторять доказательные тесты в своей ide.
4. Конкурсы. После того, как вы потратите некоторое время на изучение отчетов, можно и самим попробовать зарегистрироваться на конкурсных площадках и начать проводить аудиты. Тут вы научитесь подготавливать проект для аудита, устанавливать его зависимости и писать первые отчеты.
5. Отчеты по своим конкурсным проектам. На этой стадии вы уже читаете отчеты или находки других участников на проектах, которые вы аудировали. Очень важно просматривать каждый отчет внимательно и думать, как вы могли пропустить этот момент, и на что обращать внимание в следующий раз.
Вполне вероятно, чуть позже я добавлю еще пару стадий. Но сейчас я сам на последней из них.
Фокус и практика сделают вас прекрасным специалистом.
#audit
Постов на канале сейчас выходит очень мало, так как я с головой ушел в практику аудита. Конкурс за конкурсом с начала марта. Пока хвастаться нечем, но хочу поделиться свои новым видением про обучение.
Во-первых, web3 разработчик и web3 аудитор, хоть и оперируют одинаковыми знаниями, все таки разные профессии. Проблемы с безопасностью могут быть даже в самом крутом коде, написанным сеньорами с огромный опытом. При этом даже очень опытный аудитор, возможно, также не сможет написать достойный код, решающий определенную задачу, как это сделает человек, который сфокусирован на разработке.
Поэтому тут я скорее за разделение профессий. Фокус на чем-то одном, будет быстрее продвигать вас в обучении.
Во-вторых, для себя я определил 5 глобальных стадий обучения аудитора.
1. Обучение базовым уязвимостям в смарт контрактах. Тут будет достаточно получить понимание, чем реентранси отличается от dos атак. Ну, и знать, как их искать в коде. Для этого вообще не обязательно записываться на онлайн курсы. Вся информация есть на этом канале и в сети, на первых страницах гугла.
2. Решение задач. Ethernaut, dvd, CTE и любые другие задачи будут невероятно качественным подспорьем на этой стадии. Тут для аудитора важно будет начать определять участки кода с возможной проблемой и находить варианты взлома.
3. Аудиторские отчеты. Только после того, как вы научитесь решать задачи, стоит преступать к чтению отчетов. Можно брать отчеты с популярных площадок, типа c4, или от профессиональных аудиторов, типа obront. На этом этапе нужно понять, что уязвимости в контрактах выходят за рамки обычных задача. Будет не лишним и самому повторять доказательные тесты в своей ide.
4. Конкурсы. После того, как вы потратите некоторое время на изучение отчетов, можно и самим попробовать зарегистрироваться на конкурсных площадках и начать проводить аудиты. Тут вы научитесь подготавливать проект для аудита, устанавливать его зависимости и писать первые отчеты.
5. Отчеты по своим конкурсным проектам. На этой стадии вы уже читаете отчеты или находки других участников на проектах, которые вы аудировали. Очень важно просматривать каждый отчет внимательно и думать, как вы могли пропустить этот момент, и на что обращать внимание в следующий раз.
Вполне вероятно, чуть позже я добавлю еще пару стадий. Но сейчас я сам на последней из них.
Фокус и практика сделают вас прекрасным специалистом.
#audit
👍12❤1🔥1
Как читать аудиторские отчеты
Несколько раз меня спрашивали о том, как правильно читать отчеты или жаловались, что не могут понять некоторые моменты из них. Поэтому я решил написать небольшой пост о том, как это делаю я.
Есть несколько видов отчетов, которые я разделяю для себя:
1) Отчеты от конкурсных площадок, типа с4 или Шерлок;
2) Отчеты от компаний, типа trail of bits;
3) Отчеты от соло-аудиторов, типа trust;
4) Отчеты по взломам, типа блога Immunefi;
Для каждого из них у меня слегка различный подход цели изучения. Но сначала об общих чертах.
1. Самое главное - не весь отчет (не все баги) иногда можно понять и разобрать. Это абсолютно нормально, если вы не понимаете какой-либо момент или описание уязвимости. Особенно в High Risk разделе.
Очень часто там приводятся примеры уязвимости характерные только для данного проекта и его реализации. И вам потребовалось бы разобрать и усвоить всю кодовую базу протокола, чтобы понять, в чем была суть проблемы.
Смело пропускайте такие описания.
2. Для меня в чтении отчетов важно понимать суть уязвимости. Для этого вы можете завести свою небольшую таблицу, куда записывать баги по разделам: Access control, reentrancy, division, и т.д. И потом добавлять записи туда, например, "забыли поставить модификатор", "из-за того, что деление идет раньше умножения теряется точность" и все в этом духе.
Вы даже можете завести свой канал в Телеграме и скидывать туда пример кода и краткое описание. Для вашего личного обучение - это будет очень хорошо.
3. 99% всех проблем с газом и около 80% low-level популярных уязвимостей можно уместить в список из 50 пунктов. Звучит странно, но так и есть. Вы вполне можете составить свой из отчетов на code4rena и просто выучить его. Это проще, чем кажется. Зато в отчетах вы сможете бегло просматривать эти разделы и обращать внимание только на что-то уникальное.
4. High и Med уязвимости нужно изучать, открывая ссылки с кодом или примером в описании бага. Здесь важно получить "насмотренность" в коде, чтобы научиться определять такие же моменты в других проектах.
5. Обращайте внимание на то, как именно составлены описания уязвимостей, в смысле формат текста: что пишут в "impact", что в "PoC", что в "Recommendation". Это будет важно, когда вам потребуется самим отправлять отчеты. На эту темы позже будет еще один пост.
Теперь пройдемся по различиям в аудиторских отчетах.
1. На конкурсных площадках я обращаю внимание на формат описания уязвимостей, на их подачу. Это сложно объяснить словами, но, прочитав хотя бы по 20 отчетов с code4rena и Шерлока, вы сможете увидеть некоторую разницу. То, что на одной площадке может проходить как Med, на другой пойдет, как High.
2. В "соло" отчетах мне всегда было интересно следить за ходом мысли аудитора. Прочитав отчеты trust, можно начать понимать, на что он обращает внимание и как ведет свой процесс аудита.
3. В разборах уязвимостей от Immunefi мне было интересно те нюансы, из-за которых происходили взломы. Более того, очень часто они выставляют код для теста взлома. Будет очень хорошо, если вы повторите его у себя в Ремиксе или другом ide. Тесты крайне важны в аудите! А Immunefi дают прекрасные примеры!
Вообще, в чтении отчетов тренируется насмотренность и понимание, что уязвимостей намного больше, чем мы узнавали в задачах. Некоторые из них, просто не смогут появиться в задачах, как например с реорганизацией блоков.
Один-два отчета в день - будет лучшей практикой, чем если бы вы решили "засесть" с ними на несколько часов.
Надеюсь, этот длиннопост поможет вам наладить свой процесс с обучением.
#audit #report
Несколько раз меня спрашивали о том, как правильно читать отчеты или жаловались, что не могут понять некоторые моменты из них. Поэтому я решил написать небольшой пост о том, как это делаю я.
Есть несколько видов отчетов, которые я разделяю для себя:
1) Отчеты от конкурсных площадок, типа с4 или Шерлок;
2) Отчеты от компаний, типа trail of bits;
3) Отчеты от соло-аудиторов, типа trust;
4) Отчеты по взломам, типа блога Immunefi;
Для каждого из них у меня слегка различный подход цели изучения. Но сначала об общих чертах.
1. Самое главное - не весь отчет (не все баги) иногда можно понять и разобрать. Это абсолютно нормально, если вы не понимаете какой-либо момент или описание уязвимости. Особенно в High Risk разделе.
Очень часто там приводятся примеры уязвимости характерные только для данного проекта и его реализации. И вам потребовалось бы разобрать и усвоить всю кодовую базу протокола, чтобы понять, в чем была суть проблемы.
Смело пропускайте такие описания.
2. Для меня в чтении отчетов важно понимать суть уязвимости. Для этого вы можете завести свою небольшую таблицу, куда записывать баги по разделам: Access control, reentrancy, division, и т.д. И потом добавлять записи туда, например, "забыли поставить модификатор", "из-за того, что деление идет раньше умножения теряется точность" и все в этом духе.
Вы даже можете завести свой канал в Телеграме и скидывать туда пример кода и краткое описание. Для вашего личного обучение - это будет очень хорошо.
3. 99% всех проблем с газом и около 80% low-level популярных уязвимостей можно уместить в список из 50 пунктов. Звучит странно, но так и есть. Вы вполне можете составить свой из отчетов на code4rena и просто выучить его. Это проще, чем кажется. Зато в отчетах вы сможете бегло просматривать эти разделы и обращать внимание только на что-то уникальное.
4. High и Med уязвимости нужно изучать, открывая ссылки с кодом или примером в описании бага. Здесь важно получить "насмотренность" в коде, чтобы научиться определять такие же моменты в других проектах.
5. Обращайте внимание на то, как именно составлены описания уязвимостей, в смысле формат текста: что пишут в "impact", что в "PoC", что в "Recommendation". Это будет важно, когда вам потребуется самим отправлять отчеты. На эту темы позже будет еще один пост.
Теперь пройдемся по различиям в аудиторских отчетах.
1. На конкурсных площадках я обращаю внимание на формат описания уязвимостей, на их подачу. Это сложно объяснить словами, но, прочитав хотя бы по 20 отчетов с code4rena и Шерлока, вы сможете увидеть некоторую разницу. То, что на одной площадке может проходить как Med, на другой пойдет, как High.
2. В "соло" отчетах мне всегда было интересно следить за ходом мысли аудитора. Прочитав отчеты trust, можно начать понимать, на что он обращает внимание и как ведет свой процесс аудита.
3. В разборах уязвимостей от Immunefi мне было интересно те нюансы, из-за которых происходили взломы. Более того, очень часто они выставляют код для теста взлома. Будет очень хорошо, если вы повторите его у себя в Ремиксе или другом ide. Тесты крайне важны в аудите! А Immunefi дают прекрасные примеры!
Вообще, в чтении отчетов тренируется насмотренность и понимание, что уязвимостей намного больше, чем мы узнавали в задачах. Некоторые из них, просто не смогут появиться в задачах, как например с реорганизацией блоков.
Один-два отчета в день - будет лучшей практикой, чем если бы вы решили "засесть" с ними на несколько часов.
Надеюсь, этот длиннопост поможет вам наладить свой процесс с обучением.
#audit #report
👍11
ERC4626: Tokenized vaults
Очередное прекрасное видео от Ильи. Как вы поняли из названия, в этот раз мы поговорим о стандарте ERC4626, какие проблемы он решает и как стоит его использовать в свои проектах.
Приятного просмотра!
#erc4626
Очередное прекрасное видео от Ильи. Как вы поняли из названия, в этот раз мы поговорим о стандарте ERC4626, какие проблемы он решает и как стоит его использовать в свои проектах.
Приятного просмотра!
#erc4626
YouTube
Solidity и смарт-контракты Ethereum, урок #49 | ERC4626: Tokenized vaults (хранилища)
ХОТИТЕ СТАТЬ РАЗРАБОТЧИКОМ Solidity, узнать об Ethereum, блокчейне и многом другом ещё больше?!
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
Мои друзья из GUIDE DAO (бывшая школа MCS) предлагают скидку 0,1 ETH на ВСЕ СВОИ БУТКЕМЫ ПО КРИПТЕ! Материалы этих буткемов подготовлены мной и другими специалистами:…
👍7👏1
Аудитор, продавай свои баги
Написать этот пост меня сподвигла ситуация, которая происходила со мной на площадках code4rena и sherlock. Можно прочитать сотни аудиторских отчетов, понять важные уязвимости и методы их предотвращения, но упустить из виду один важный момент: то, как пишутся сами отчеты.
Поначалу, я думал, что баг есть баг: если ты его нашел, то молодец, получай оплату. Но не тут-то было.
Помимо того, что тебе нужно порой написать доказательные тесты, также очень важно "продать" свой баг в его описании.
Посмотрите на мой репорт для конкурса Дерби. На тот момент я не придал особого значения тому, что функции открыты для всех. Не, конечно, я знаю, что такого быть не должно, поэтому просто указал, что их нужно защитить.
Тем не менее, его отклонили. Однако этот репорт пометили, как High, а сам аудитор получил $2382.89 USDC, хотя суть проблемы такая же: доступ к функциям для всех.
Другая находка из аудита протокола Kairos, которую отклонили судьи, особо не вникая.
Если бы я расписал доказательство немного по другому, без указания, что админы могут повлиять на это, полагаю, что ее бы приняли.
Третья, как мне кажется, валидная находка была в протоколе Токио, которая была принята судьями, но отвергнута самими разработчиками. Если бы было сделано описание как это может повлиять на работу проекта в будущем с приведенными цифрами, уверен, что итоговое решение было бы другим.
Для себя я вынес несколько правил по работе с конкурсными площадками, да и в целом, по работе аудитора:
1. Нужно уметь продать свой баг. В одном из интервью на ютуб аудитор сказал, что он сначала находит проблемное место, а потом, грубо говоря, "раздувает" его. Поэтому когда вы находите даже самый маленький баг, нужно описать его максимально "страшно" с приведенными доказательствами и участками кода;
2. Даже если баг валидный, его могут отклонить, просто потому, что судья или другой разработчик не увидят проблемы в нем. Ваша находка может быть единственной в отчете, но не принятой из-за недостаточного описания.
3. Очень часто на конкурсах ставится флажок, что админ \ модератор по-умолчанию хорошие ребята и все связанные с ними бага исключаются. Старайтесь не приплетать админов протокола к ответственности, даже когда проблема напрямую зависит от них. Старайтесь описывать проблему, а не качества админа.
4. У каждого разработчика есть чувство собственного величия, и находя баги в его коде, вы сильно раните его чувства. Поэтому для многих из них текстовые описания не будут иметь никакого значения, и они будут старательно комментировать, что это надуманные баги. Прилагайте тесты. Вопросов будет меньше.
Сейчас даже сложно представить, сколько валидных багов было упущено на платформах из-за плохого описания. Но, что самое интересное, этому никто и никогда не учит: ни на курсах, ни от аудиторов.
В следующий раз, найдя баг и открыв форму для отчета, потратьте чуть больше времени на описание проблемы.
#audit #report
Написать этот пост меня сподвигла ситуация, которая происходила со мной на площадках code4rena и sherlock. Можно прочитать сотни аудиторских отчетов, понять важные уязвимости и методы их предотвращения, но упустить из виду один важный момент: то, как пишутся сами отчеты.
Поначалу, я думал, что баг есть баг: если ты его нашел, то молодец, получай оплату. Но не тут-то было.
Помимо того, что тебе нужно порой написать доказательные тесты, также очень важно "продать" свой баг в его описании.
Посмотрите на мой репорт для конкурса Дерби. На тот момент я не придал особого значения тому, что функции открыты для всех. Не, конечно, я знаю, что такого быть не должно, поэтому просто указал, что их нужно защитить.
Тем не менее, его отклонили. Однако этот репорт пометили, как High, а сам аудитор получил $2382.89 USDC, хотя суть проблемы такая же: доступ к функциям для всех.
Другая находка из аудита протокола Kairos, которую отклонили судьи, особо не вникая.
Если бы я расписал доказательство немного по другому, без указания, что админы могут повлиять на это, полагаю, что ее бы приняли.
Третья, как мне кажется, валидная находка была в протоколе Токио, которая была принята судьями, но отвергнута самими разработчиками. Если бы было сделано описание как это может повлиять на работу проекта в будущем с приведенными цифрами, уверен, что итоговое решение было бы другим.
Для себя я вынес несколько правил по работе с конкурсными площадками, да и в целом, по работе аудитора:
1. Нужно уметь продать свой баг. В одном из интервью на ютуб аудитор сказал, что он сначала находит проблемное место, а потом, грубо говоря, "раздувает" его. Поэтому когда вы находите даже самый маленький баг, нужно описать его максимально "страшно" с приведенными доказательствами и участками кода;
2. Даже если баг валидный, его могут отклонить, просто потому, что судья или другой разработчик не увидят проблемы в нем. Ваша находка может быть единственной в отчете, но не принятой из-за недостаточного описания.
3. Очень часто на конкурсах ставится флажок, что админ \ модератор по-умолчанию хорошие ребята и все связанные с ними бага исключаются. Старайтесь не приплетать админов протокола к ответственности, даже когда проблема напрямую зависит от них. Старайтесь описывать проблему, а не качества админа.
4. У каждого разработчика есть чувство собственного величия, и находя баги в его коде, вы сильно раните его чувства. Поэтому для многих из них текстовые описания не будут иметь никакого значения, и они будут старательно комментировать, что это надуманные баги. Прилагайте тесты. Вопросов будет меньше.
Сейчас даже сложно представить, сколько валидных багов было упущено на платформах из-за плохого описания. Но, что самое интересное, этому никто и никогда не учит: ни на курсах, ни от аудиторов.
В следующий раз, найдя баг и открыв форму для отчета, потратьте чуть больше времени на описание проблемы.
#audit #report
👍19
Шаблон для форка и тестов в Foundry
В Твиттере поделились новой библиотекой для простого форка EVM совместимых сетей и написания тестов.
По сути это некий шаблон, который можно подключать в свой проект и быстро подготавливать среду для тестирования.
#foundry #fork
В Твиттере поделились новой библиотекой для простого форка EVM совместимых сетей и написания тестов.
По сути это некий шаблон, который можно подключать в свой проект и быстро подготавливать среду для тестирования.
#foundry #fork
👍2
По следам одного теста
Вчера проходил небольшой тест и там встретились некоторые интересные вопросы. При изучении Solidity вы могли уже сталкиваться с подобными нюансами, а если нет, то краткое содержание этого поста будет как раз кстати.
Просто перечислю некоторые факты:
1) StaticCall не может приводить к изменениям в storage, как это может быть с Call, CallCode и DelegateCall;
2) View и pure не могут порождать события, так как это, по сути, модификация storage;
3) Pure функции не могут читать переменные state;
4) Помимо type(T).min и type(T).max есть еще type(c).name, type(c).creationCode, type(c).runtimeCode, type(i).interfaceId;
5) Конструктор контракта не может принимать calldata как параметр;
6) Комментарии не учитываются в байткоде контракта;
Надеюсь, это однажды поможет вам.
P.S. Если у вас были интересные вопросы на собеседовании, прошу поделиться ими в комментариях. Очень поможете для создания подборки!
#solidity #tips
Вчера проходил небольшой тест и там встретились некоторые интересные вопросы. При изучении Solidity вы могли уже сталкиваться с подобными нюансами, а если нет, то краткое содержание этого поста будет как раз кстати.
Просто перечислю некоторые факты:
1) StaticCall не может приводить к изменениям в storage, как это может быть с Call, CallCode и DelegateCall;
2) View и pure не могут порождать события, так как это, по сути, модификация storage;
3) Pure функции не могут читать переменные state;
4) Помимо type(T).min и type(T).max есть еще type(c).name, type(c).creationCode, type(c).runtimeCode, type(i).interfaceId;
5) Конструктор контракта не может принимать calldata как параметр;
6) Комментарии не учитываются в байткоде контракта;
Надеюсь, это однажды поможет вам.
P.S. Если у вас были интересные вопросы на собеседовании, прошу поделиться ими в комментариях. Очень поможете для создания подборки!
#solidity #tips
👍15
Немного нового для общего развития
Скоро начнется новый конкурсный аудит, и я буду реже делать посты на канале некоторое время. Но оставить вас одних без интересной информации будет не правильно, поэтому я подготовил для вас пару статей.
Знаете ли вы такие понятия как: Bloom Filter, Intrinsic Gas или Liquidity Bootstrap? Об этом тоже могут спросить на собеседовании...
Начнем с более простого: Liquidity Bootstrap. Об этом можно узнать в небольшой ветке в Твиттере от GabrielGFoo тут.
Далее огромная популярная статья, на которую стоит потратить время What happens when you send 1 DAI. Автор в деталях описывает все внутренние процессы, которые происходят при пересылке токена с одного кошелька на другой. Примечательно то, что он рассказывает и про работу узлов, и про действия валидаторов, и описывает, какие опкоды применяются в той или иной ситуации. Помимо того, что отсюда вы узнаете, что такое Intrinsic Gas, так еще и получите массу другой интересно инфы: например, какой может быть максимальный размер транзакции?
В завершении, можно еще чуть углубиться в работу EVM и узнать про работу Bloom Filter из этой статьи.
Все статьи на английском языке и написаны с технической точки зрения. У меня ушло несколько часов, чтобы разобрать и вникнуть в каждую из них.
Бонусом будет изложение Ethereum Yellow Papers в человекопонятном изложении. Там автор убрал достаточно большое количество математических формул и постарался описать все нормальным языком. Если вы не смогли осилить оригинал, то начать с этого будет верным решением.
Приятного изучения!
#yellowpapers #yellow #bloom #bloomfilter #intristic #gas #bootstrap
Скоро начнется новый конкурсный аудит, и я буду реже делать посты на канале некоторое время. Но оставить вас одних без интересной информации будет не правильно, поэтому я подготовил для вас пару статей.
Знаете ли вы такие понятия как: Bloom Filter, Intrinsic Gas или Liquidity Bootstrap? Об этом тоже могут спросить на собеседовании...
Начнем с более простого: Liquidity Bootstrap. Об этом можно узнать в небольшой ветке в Твиттере от GabrielGFoo тут.
Далее огромная популярная статья, на которую стоит потратить время What happens when you send 1 DAI. Автор в деталях описывает все внутренние процессы, которые происходят при пересылке токена с одного кошелька на другой. Примечательно то, что он рассказывает и про работу узлов, и про действия валидаторов, и описывает, какие опкоды применяются в той или иной ситуации. Помимо того, что отсюда вы узнаете, что такое Intrinsic Gas, так еще и получите массу другой интересно инфы: например, какой может быть максимальный размер транзакции?
В завершении, можно еще чуть углубиться в работу EVM и узнать про работу Bloom Filter из этой статьи.
Все статьи на английском языке и написаны с технической точки зрения. У меня ушло несколько часов, чтобы разобрать и вникнуть в каждую из них.
Бонусом будет изложение Ethereum Yellow Papers в человекопонятном изложении. Там автор убрал достаточно большое количество математических формул и постарался описать все нормальным языком. Если вы не смогли осилить оригинал, то начать с этого будет верным решением.
Приятного изучения!
#yellowpapers #yellow #bloom #bloomfilter #intristic #gas #bootstrap
🔥11👍1
Заметка по Access List и Transaction types
В статье про пересылку 1 DAI я встретил упоминание стандартов EIP-2930 (Access List) и EIP-2718 (Transaction types).
Хочу оставить тут небольшое напоминание, если вдруг однажды в тестовых вопросах попадется пункт про одного из них.
Итак, кратко говоря, ERP-2930 позволяет сэкономить немного газа при вызовах из одного контракта в другой, определяя наперед, какие контракты и слоты памяти будут нужны.
Если вы не знакомы с понятиями "горячего", "теплого" и "холодного" доступа к слотам, то поищите эту информацию на канале выше.
С помощью этого EIP, например, вместо холодного обращения стоимостью 2600 газа за Call и 2100 газа SLOAD, транзакция потребует 2400 и 1900 газа за холодный вызов сразу и после только 100 газа за уже теплые обращения.
Что же касается EIP-2718, то вы могли встречать такую строку при формировании транзакции:
0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])
так вот, 0х02 - это и есть один из типов транзакций.
Всего, с новым предложением, их может быть 128 - от 0х00 до 0x7f. Я нашел описание трех:
0х00 - Legacy type, где требовались параметры nonce, gasPrice, gasLimit, to, value, data, v, r, и s.
0х01 - такой же как и legacy, но добавляется accessList из EIP-2930.
0х02 - транзакции представленные во время Лондонского форка с предложением EIP-1559. Пример был выше.
0x03 - в разработке в предложении EIP-4844
P.S. Про другие типы пока не нашел, если у вас есть ссылки про них, буду рад почитать и потом написать пост.
#2930 #2718 #tx #accesslist #access
В статье про пересылку 1 DAI я встретил упоминание стандартов EIP-2930 (Access List) и EIP-2718 (Transaction types).
Хочу оставить тут небольшое напоминание, если вдруг однажды в тестовых вопросах попадется пункт про одного из них.
Итак, кратко говоря, ERP-2930 позволяет сэкономить немного газа при вызовах из одного контракта в другой, определяя наперед, какие контракты и слоты памяти будут нужны.
Если вы не знакомы с понятиями "горячего", "теплого" и "холодного" доступа к слотам, то поищите эту информацию на канале выше.
С помощью этого EIP, например, вместо холодного обращения стоимостью 2600 газа за Call и 2100 газа SLOAD, транзакция потребует 2400 и 1900 газа за холодный вызов сразу и после только 100 газа за уже теплые обращения.
Что же касается EIP-2718, то вы могли встречать такую строку при формировании транзакции:
0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])
так вот, 0х02 - это и есть один из типов транзакций.
Всего, с новым предложением, их может быть 128 - от 0х00 до 0x7f. Я нашел описание трех:
0х00 - Legacy type, где требовались параметры nonce, gasPrice, gasLimit, to, value, data, v, r, и s.
0х01 - такой же как и legacy, но добавляется accessList из EIP-2930.
0х02 - транзакции представленные во время Лондонского форка с предложением EIP-1559. Пример был выше.
0x03 - в разработке в предложении EIP-4844
P.S. Про другие типы пока не нашел, если у вас есть ссылки про них, буду рад почитать и потом написать пост.
#2930 #2718 #tx #accesslist #access
👍2
Немного чисел EVM и Solidity
Максимальный размер транзакции - 124kb.
Максимальный размер контракта - 24kb.
Максимальное кол-во аргументов в функции - 16.
Максимальный размер слота памяти - 32 байта.
Максимальный размер storage - 2**256 слотов.
Максимальный размер stack - 1024.
Максимальное кол-во суб-вывовов в транзакции - 1024.
Максимальное кол-во типов транзакций - 128.
Количество опкодов - 140, максимально - 256.
Последний EIP (на момент поста) - 6913.
Hard limit of type(uint64).max (0xffffffffffffffff) for the free memory pointer.
P.S. Вспомните что-то еще, добавляйте в комментарии.
#numbers
Максимальный размер транзакции - 124kb.
Максимальный размер контракта - 24kb.
Максимальное кол-во аргументов в функции - 16.
Максимальный размер слота памяти - 32 байта.
Максимальный размер storage - 2**256 слотов.
Максимальный размер stack - 1024.
Максимальное кол-во суб-вывовов в транзакции - 1024.
Максимальное кол-во типов транзакций - 128.
Количество опкодов - 140, максимально - 256.
Последний EIP (на момент поста) - 6913.
Hard limit of type(uint64).max (0xffffffffffffffff) for the free memory pointer.
P.S. Вспомните что-то еще, добавляйте в комментарии.
#numbers
👍8❤5
Сборник заметок по Solidity
На некоторых каналах и в чатах промелькнул прекрасный сборник заметок от Chinmaya, который он сам собирал продолжительное время.
На мой взгляд, его стоит изучить достаточно досконально, так как многие вопросы могут попасться в тестах при приеме на работу или других квалификационных работах.
Для себя я перекинул его в Google документы, чтобы можно было быстро удалять или комментировать некоторые пункты.
В общем, советую всем присмотреться на него: и начинающим разработчикам, и продвинутым аудиторам.
#solidity #hint
На некоторых каналах и в чатах промелькнул прекрасный сборник заметок от Chinmaya, который он сам собирал продолжительное время.
На мой взгляд, его стоит изучить достаточно досконально, так как многие вопросы могут попасться в тестах при приеме на работу или других квалификационных работах.
Для себя я перекинул его в Google документы, чтобы можно было быстро удалять или комментировать некоторые пункты.
В общем, советую всем присмотреться на него: и начинающим разработчикам, и продвинутым аудиторам.
#solidity #hint
👍6👏2
Немного вечерней рефлексии
Уже скоро будет год, как я веду данный канал, а посты и обучение все никак не заканчиваются.
Для всех тех, кто хотел выучить Solidity "по быстрому", на курсах за 30 дней или по видео на ютуб за 60 - знайте, это невозможно. Нет, конечно, научиться писать простые контракты можно, как и запустить свой токен или залить NFT на OpenSea, но для чего-то серьезного учиться придется постоянно.
Только первые полгода с июня по ноябрь я просмотрел сотни видео по работе с языком, прочитал огромное количество статей ии постов, пока не пришел к идеи стать аудитором. С тех пор, я могу отметить каждый последующий месяц, какой-либо основной идеей и этапом в своем обучении.
Ноябрь - я решил стать аудитором смарт контрактов и проходил популярные CTF, типа Ethernaut, Damn Vulnerable Defi, Capture the Ether и другие.
Декабрь - Углубление в тему безопасности и изучение популярных уязвимостей.
Январь - первый заход на конкурсные площадки. Тогда я понял, что умею писать тесты не так хорошо.
Февраль - обучение написанию тестов на Foundry и изучение основных моментов в проведении аудита.
Март - второй заход на конкурсные площадки. Изучение механик аудита и основных нюансов.
Апрель - тут я понял, что написание отчетов - это отдельный вид работы аудитора. Весь месяц подбирал для себя шаблон и примеры других отчетов.
Май - сейчас я планирую подтянуть знания для прохождения тестов и собеседований. Как оказалось, нужно знать куда больше "моментов", чтобы устроиться в хорошую зарубежную компанию.
При этом, в течение каждого из перечисленных месяцев я не переставал изучать аудиторские отчеты, статьи о взломах и другие материалы по своей профессии.
Думаете, теперь я много знаю? Много. Но и этого не достаточно для того, чтобы попасть в хорошую зарубежную компанию.
Ну, что же, посмотрим, что будет дальше.
Продолжаем учиться вместе!
#thoughts
Уже скоро будет год, как я веду данный канал, а посты и обучение все никак не заканчиваются.
Для всех тех, кто хотел выучить Solidity "по быстрому", на курсах за 30 дней или по видео на ютуб за 60 - знайте, это невозможно. Нет, конечно, научиться писать простые контракты можно, как и запустить свой токен или залить NFT на OpenSea, но для чего-то серьезного учиться придется постоянно.
Только первые полгода с июня по ноябрь я просмотрел сотни видео по работе с языком, прочитал огромное количество статей ии постов, пока не пришел к идеи стать аудитором. С тех пор, я могу отметить каждый последующий месяц, какой-либо основной идеей и этапом в своем обучении.
Ноябрь - я решил стать аудитором смарт контрактов и проходил популярные CTF, типа Ethernaut, Damn Vulnerable Defi, Capture the Ether и другие.
Декабрь - Углубление в тему безопасности и изучение популярных уязвимостей.
Январь - первый заход на конкурсные площадки. Тогда я понял, что умею писать тесты не так хорошо.
Февраль - обучение написанию тестов на Foundry и изучение основных моментов в проведении аудита.
Март - второй заход на конкурсные площадки. Изучение механик аудита и основных нюансов.
Апрель - тут я понял, что написание отчетов - это отдельный вид работы аудитора. Весь месяц подбирал для себя шаблон и примеры других отчетов.
Май - сейчас я планирую подтянуть знания для прохождения тестов и собеседований. Как оказалось, нужно знать куда больше "моментов", чтобы устроиться в хорошую зарубежную компанию.
При этом, в течение каждого из перечисленных месяцев я не переставал изучать аудиторские отчеты, статьи о взломах и другие материалы по своей профессии.
Думаете, теперь я много знаю? Много. Но и этого не достаточно для того, чтобы попасть в хорошую зарубежную компанию.
Ну, что же, посмотрим, что будет дальше.
Продолжаем учиться вместе!
#thoughts
👍35
RACE #17 Of The Secureum Bootcamp
Недавно прошел очередной тест Race, который достоин обратить на себя внимание начинающих аудиторов.
Во-первых, вы поймете различия в ++i от i++ на примере.
Во-вторых, узнаете чуть больше об одном популярном контракте OZ.
В-третьих, напомните себе о том, как работает approve.
Очень классный тест!
P.S. у меня получилось только два правильных "чистых ответа". Остальные 6 - были и правильней и не правильней ответы в каждом вопросе.
#race #i++
Недавно прошел очередной тест Race, который достоин обратить на себя внимание начинающих аудиторов.
Во-первых, вы поймете различия в ++i от i++ на примере.
Во-вторых, узнаете чуть больше об одном популярном контракте OZ.
В-третьих, напомните себе о том, как работает approve.
Очень классный тест!
P.S. у меня получилось только два правильных "чистых ответа". Остальные 6 - были и правильней и не правильней ответы в каждом вопросе.
#race #i++
👍7
Foundry Safer Log
Небольшая библиотека от Philogy для повышения качества работы с Foundry, а точнее с логированием событий.
По словам Philogy, стандартные настройки Foundry модифицируют память, что порой мешает дебагу low-level assembly в последствии. С данным решением об этом можно не беспокоиться.
P.S. Скоро придется делать пост "Работаем с Foundry: с 0 до pro"!
#foundry #forge
Небольшая библиотека от Philogy для повышения качества работы с Foundry, а точнее с логированием событий.
По словам Philogy, стандартные настройки Foundry модифицируют память, что порой мешает дебагу low-level assembly в последствии. С данным решением об этом можно не беспокоиться.
P.S. Скоро придется делать пост "Работаем с Foundry: с 0 до pro"!
#foundry #forge
🔥4
Подготовка к собеседованию в зарубежную компанию
В этом месяце я решил провести полноценную подготовку к прохождению собеседований в зарубежные компании. И сейчас публикую первую подборку статей, которые крайне рекомендую изучить и понять каждому. Все ресурсы, понятное дело, на английском языке.
Скорее всего, позже в этом месяце будет сделана вторая подборка материалов, так как еще не все изучено из того, что планировал и сохранял.
Итак, сохраняйте себе!
1. Для начала нужно понимать как работает память в Solidity. Вот тут вы найдете одну из лучших статей, которая рассказывает о работе с памятью.
2. Далее следует разобраться как работает EVM во время вызовов между контрактами. Эта серия статей поможет нам.
3. Часто встречал вопросы про опкоды. Вот тут можно потренироваться решать пазлы, а вот тут почитать решения. На самом деле, статья с решениями помогла мне намного больше, чем задачки.
4. Серия статей от Open Zeppelin расскажет как работают смарт контракты.
5. Подборка нюансов о Solidity и EVM, которая недавно уже была на канале, просто обязана быть в этой подборке!
6. Побитовые операции. Простая тема, которая доходила до меня дольше всего. А может все еще и доходит... Но хотя бы базис знать надо.
7. Популярная статья What happens when you send 1 DAI. Просто обязательна к прочтению каждому разработчику и аудитору.
8. Yul и assembly другой камень преткновения многих начинающих свой путь в web3. Тут довольно просто и детально все описано. Лучше практиковаться в своей IDE или Remix.
9. Последняя на сегодня это статья про MEV. Интересная и сложная одновременно. Вопросов по этой теме не так уже много, но лучше бы быть в курсе.
На изучение этой подборки может уйти от пары недель до пары месяцев. После этого изучения вы сможете ответить на многие вопросы на собеседовании, ну или хотя бы показаться человеком знающим.
Приятного обучения!
#interview
В этом месяце я решил провести полноценную подготовку к прохождению собеседований в зарубежные компании. И сейчас публикую первую подборку статей, которые крайне рекомендую изучить и понять каждому. Все ресурсы, понятное дело, на английском языке.
Скорее всего, позже в этом месяце будет сделана вторая подборка материалов, так как еще не все изучено из того, что планировал и сохранял.
Итак, сохраняйте себе!
1. Для начала нужно понимать как работает память в Solidity. Вот тут вы найдете одну из лучших статей, которая рассказывает о работе с памятью.
2. Далее следует разобраться как работает EVM во время вызовов между контрактами. Эта серия статей поможет нам.
3. Часто встречал вопросы про опкоды. Вот тут можно потренироваться решать пазлы, а вот тут почитать решения. На самом деле, статья с решениями помогла мне намного больше, чем задачки.
4. Серия статей от Open Zeppelin расскажет как работают смарт контракты.
5. Подборка нюансов о Solidity и EVM, которая недавно уже была на канале, просто обязана быть в этой подборке!
6. Побитовые операции. Простая тема, которая доходила до меня дольше всего. А может все еще и доходит... Но хотя бы базис знать надо.
7. Популярная статья What happens when you send 1 DAI. Просто обязательна к прочтению каждому разработчику и аудитору.
8. Yul и assembly другой камень преткновения многих начинающих свой путь в web3. Тут довольно просто и детально все описано. Лучше практиковаться в своей IDE или Remix.
9. Последняя на сегодня это статья про MEV. Интересная и сложная одновременно. Вопросов по этой теме не так уже много, но лучше бы быть в курсе.
На изучение этой подборки может уйти от пары недель до пары месяцев. После этого изучения вы сможете ответить на многие вопросы на собеседовании, ну или хотя бы показаться человеком знающим.
Приятного обучения!
#interview
🔥32👍3
Большая заметка по работе с памятью
Несмотря на то, что на канале уже было достаточно материалов по работе с памятью в Solidity, я постоянно путался в некоторых моментах. Поэтому решил объединить все в одном посте-заметке, чтобы иметь быстрый доступ и периодически напоминать себе основные нюансы.
Storage
1. Размер Storage контракта 2**256-1.
2. Слоты в памяти имеют размер в 32 байта. Если переменные меньше 32 байт, то они могут быть "упакованы". Т.е. если есть 4 переменные uint8, то они все будут занимать только один слот.
3. Динамические массивы хранятся следующим образом: сначала определяется слот, в котором массив был обозначен. Там хранится его длина (кол-во элементов), а значение элемента в массиве высчитывается через keccak256(p), где "р" - номер слота инициализации массива. Таким образом, первый элемент массива будет храниться в keccak256(p), второй в keccak256(p)+1, третий в keccak256(p)+2 и т.д.
4. Маппинга хранятся немного по другому. В главном слоте, где был объявлен маппинг, хранится пустое значение (все нули). А значение маппинга находится с помощью keccak256(p CONCAT key), где key - это ключ, к которому нужно найти само значение.
5. Enum, по описанию из комментария на stackexchange: Up to 255 values seems to take up 8 bits of storage, and 256 values seems to take up 16 bits of storage.
Memory
1. Максимальный размер Memory - 2 ** 64 байта.
2. Стоимость хранения считается linearly для первых 724 байтов, и Quadratically - после.
3. Структура памяти:
0x00 - 0x3f (64 bytes): зарезервированное место для хеширования;
0x40 - 0x5f (32 bytes): указатель на свободное место (free memory pointer);
0x60 - 0x7f (32 bytes): пустой слот, который также используется, как изначальное значение для динамических массивов;
Отсчет для хранения новых значений начинается с 128 байта.
4. Слоты всегда по 32 байта.
5. Для динамических массивов в первом слоте хранится его длина, а затем идут сами элементы.
6. Если добавляете значения в Memory через assembly, то также необходимо обновлять и free memory pointer, так как в этом случае он не обновляется автоматически.
7. Все не инициализированные значение будут указывать на слот 0х60 (кроме структур), в то время как строки, байти и динамические массивы будут указывать на следующий free memory location.
Calldata
1. Неизменяемое хранилище данных.
2. Не могут храниться и передаваться маппинги.
3. В отличие от Memory размер не лимитирован.
4. Размер всего calldata можно узнать с помощью опкода CALLDATASIZE.
5. Первые 4 байта всегда занимает селектор функции, который считается через bytes4(keccak256("funcName(args)")).
6. Для динамических массивов и строк сначала идет offset (32 байта), потом длина / размер (32 байта), потом сами значения.
Stack
1. Хранение по принципу LIFO - last in, first out.
2. В стеке доступны только верхние 16 слотов.
3. Базовые опкоды: PUSH, POP, SWAP и DUP.
4. Solidity, как язык, не работает на прямую со стеком.
5. Функции помеченные, как external, занимают два слота в стеке: адрес контракта и селектор вызываемой функции. В этом случае они zero-padded слева, а не справа, как это в других случаях.
6. Для того, чтобы обойти ошибку "stack too deep" можно использовать block scopes {}.
Code
1. Константы и immutable хранятся в байткоде контракта.
2. Если константы на определены по какой-либо причине, то они на попадают в байткод.
3. Immutable нельзя определять в try/catch в версии 0.8.20.
4. Аргументы для конструктора контракта добавляются в конец байтокода самого контракта.
P.S. Можете смело корректировать или добавлять пункты в комментариях.
#storage #memory #calldata #code #stack
Несмотря на то, что на канале уже было достаточно материалов по работе с памятью в Solidity, я постоянно путался в некоторых моментах. Поэтому решил объединить все в одном посте-заметке, чтобы иметь быстрый доступ и периодически напоминать себе основные нюансы.
Storage
1. Размер Storage контракта 2**256-1.
2. Слоты в памяти имеют размер в 32 байта. Если переменные меньше 32 байт, то они могут быть "упакованы". Т.е. если есть 4 переменные uint8, то они все будут занимать только один слот.
3. Динамические массивы хранятся следующим образом: сначала определяется слот, в котором массив был обозначен. Там хранится его длина (кол-во элементов), а значение элемента в массиве высчитывается через keccak256(p), где "р" - номер слота инициализации массива. Таким образом, первый элемент массива будет храниться в keccak256(p), второй в keccak256(p)+1, третий в keccak256(p)+2 и т.д.
4. Маппинга хранятся немного по другому. В главном слоте, где был объявлен маппинг, хранится пустое значение (все нули). А значение маппинга находится с помощью keccak256(p CONCAT key), где key - это ключ, к которому нужно найти само значение.
5. Enum, по описанию из комментария на stackexchange: Up to 255 values seems to take up 8 bits of storage, and 256 values seems to take up 16 bits of storage.
Memory
1. Максимальный размер Memory - 2 ** 64 байта.
2. Стоимость хранения считается linearly для первых 724 байтов, и Quadratically - после.
3. Структура памяти:
0x00 - 0x3f (64 bytes): зарезервированное место для хеширования;
0x40 - 0x5f (32 bytes): указатель на свободное место (free memory pointer);
0x60 - 0x7f (32 bytes): пустой слот, который также используется, как изначальное значение для динамических массивов;
Отсчет для хранения новых значений начинается с 128 байта.
4. Слоты всегда по 32 байта.
5. Для динамических массивов в первом слоте хранится его длина, а затем идут сами элементы.
6. Если добавляете значения в Memory через assembly, то также необходимо обновлять и free memory pointer, так как в этом случае он не обновляется автоматически.
7. Все не инициализированные значение будут указывать на слот 0х60 (кроме структур), в то время как строки, байти и динамические массивы будут указывать на следующий free memory location.
Calldata
1. Неизменяемое хранилище данных.
2. Не могут храниться и передаваться маппинги.
3. В отличие от Memory размер не лимитирован.
4. Размер всего calldata можно узнать с помощью опкода CALLDATASIZE.
5. Первые 4 байта всегда занимает селектор функции, который считается через bytes4(keccak256("funcName(args)")).
6. Для динамических массивов и строк сначала идет offset (32 байта), потом длина / размер (32 байта), потом сами значения.
Stack
1. Хранение по принципу LIFO - last in, first out.
2. В стеке доступны только верхние 16 слотов.
3. Базовые опкоды: PUSH, POP, SWAP и DUP.
4. Solidity, как язык, не работает на прямую со стеком.
5. Функции помеченные, как external, занимают два слота в стеке: адрес контракта и селектор вызываемой функции. В этом случае они zero-padded слева, а не справа, как это в других случаях.
6. Для того, чтобы обойти ошибку "stack too deep" можно использовать block scopes {}.
Code
1. Константы и immutable хранятся в байткоде контракта.
2. Если константы на определены по какой-либо причине, то они на попадают в байткод.
3. Immutable нельзя определять в try/catch в версии 0.8.20.
4. Аргументы для конструктора контракта добавляются в конец байтокода самого контракта.
P.S. Можете смело корректировать или добавлять пункты в комментариях.
#storage #memory #calldata #code #stack
👍11💯3❤2🔥2