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
Сводный пост про основные DeFi
Решил для себя написать небольшую заметку, к которой мог бы обращаться, чтобы напомнить об основных особенностях какого-либо протокола. Порой на собеседовании могут спросить об этом, поэтому такую напоминалку лучше держать под рукой.
P.S. Если знаете, что можно добавить, смело пишите в комментарии. Пост будет дополняться.
Balancer
1. Один из самых популярных DEX (AMM) протоколов;
2. Есть две версии протокола. Главное отличие V1 от V2 в том, что в V2 существует только один Vault, который держит и управляет всеми активами пулов.
3. V2 также более gas efficient, так как операции происходят в одном Vault, и пользователям не нужно переводить активы с одного пула в другой. Все работает с внутренним балансом.
Инструменты: swaps, weighted pool (like Uniswap), stable pool, boosted pool, bootstrapping pool, linear pool
Governance: BAL token
Uniswap
1. V1 - только пулы токен\эфир;
2. V2 - пулы токен\токен;
3. V3 - концентрированная ликвидность, NFT токен ликвидности, возможность добавить только один токен в пул. Также есть принципы активной ликвидности (при выходе из границ - стоп на проценты), и разные комиссии для разных пулов.
4. Наличие twap oracles в V3.
Инструменты: swaps, flash swaps, flash loan, mine liquidity, oracle
Governance: UNI token
Curve
1. DEX (AMM) для обмена stablecoins.
2. Развернут в 10 сетях: Ethereum, Arbitrum, Aurora, Avalanche, Fantom, Harmony, Optimism, Polygon, xDai и Moonbeam.
3. Смарт контракты пулов могут содержать два и более токенов.
4. В Curve V2 добавили возможность обмена между нескоррелированными активами. В частности, запустили пул WETH/WBTC/USDT.
5. В новой версии также ввели функцию автоматической концентрации ликвидности вокруг текущей цены. За счет этого пользователи смогли обменивать большие суммы с минимальным проскальзыванием.
6. Чтобы предложение было принято, в голосовании должно участвовать не менее 30% существующих veCRV, из которых не менее 51% должны его поддержать.
Инструменты: swaps, farming,
Governance: CRV token
1inch
1. DEX агрегатор.
2. Собирает цены на токены с различных бирж и предоставляет лучшую для обмена.
Инструменты: limit order, swap, farming, wallet
Governance: 1INCH token
dydx
1. DEX базирующаяся на Ethereum layer 2 system StarkWare (ZK).
2. создана для торговли perpetuals. Подобно опционам и фьючерсам, это позволяет спекулировать на будующей цене активов. Однако, в отличие от них же, perpetuals не имеют даты окончания срока действия.
3. dydx работает не как AMM, а по принципу стандартных orderbook.
Инструменты: ордера (perpetuals)
Governance: dydx token
Apollo dex
1. Является первой гибридной биржей CEX-DEX, но с ноября 2022 стала полностью DEX.
Инструменты: обмен и торговля деривативами, staking
Governance: apx token
Compound
1. Работает с переобеспеченными займами.
2. Если у вас есть Эфир на протоколе, то он конвертируется в cETH.
Инструменты: lending & borrowing
Governance: COMP token
Aave
1. Работает с переобеспеченными займами.
2. Предлагает пулы для активов off-chain: недвижимость, cargo and freight invoices.
3. В V3 версии появился Portal, который позволяет работать между сетями блокчейна.
Инструменты: lending & borrowing, flash loan
Governance: aave token
MakerDAO
1. Позволяет закладывать Эфир, чтобы получить токен DAI.
2. Своя система ликвидации и поддержания стабильной цены DAI.
3.В ноябре 2019 года сообщество проекта решило перейти к мультизалоговой системе — то есть позволить пользователям использовать для залога разные криптовалюты.
4. MakerDAO стал первым DeFi-протоколом, который стал принимать в залог акции публичных компаний.
5. Работает смарт-контракт под названием DAI Savings Rate (DSR) — это переменная ставка начислений от токенов DAI, заблокированных в смарт-контракте DSR.
6. Действует особый стабилизационный сбор (Stability Fee).
Инструменты: lending
Governance: mkr token
#dex #defi
Решил для себя написать небольшую заметку, к которой мог бы обращаться, чтобы напомнить об основных особенностях какого-либо протокола. Порой на собеседовании могут спросить об этом, поэтому такую напоминалку лучше держать под рукой.
P.S. Если знаете, что можно добавить, смело пишите в комментарии. Пост будет дополняться.
Balancer
1. Один из самых популярных DEX (AMM) протоколов;
2. Есть две версии протокола. Главное отличие V1 от V2 в том, что в V2 существует только один Vault, который держит и управляет всеми активами пулов.
3. V2 также более gas efficient, так как операции происходят в одном Vault, и пользователям не нужно переводить активы с одного пула в другой. Все работает с внутренним балансом.
Инструменты: swaps, weighted pool (like Uniswap), stable pool, boosted pool, bootstrapping pool, linear pool
Governance: BAL token
Uniswap
1. V1 - только пулы токен\эфир;
2. V2 - пулы токен\токен;
3. V3 - концентрированная ликвидность, NFT токен ликвидности, возможность добавить только один токен в пул. Также есть принципы активной ликвидности (при выходе из границ - стоп на проценты), и разные комиссии для разных пулов.
4. Наличие twap oracles в V3.
Инструменты: swaps, flash swaps, flash loan, mine liquidity, oracle
Governance: UNI token
Curve
1. DEX (AMM) для обмена stablecoins.
2. Развернут в 10 сетях: Ethereum, Arbitrum, Aurora, Avalanche, Fantom, Harmony, Optimism, Polygon, xDai и Moonbeam.
3. Смарт контракты пулов могут содержать два и более токенов.
4. В Curve V2 добавили возможность обмена между нескоррелированными активами. В частности, запустили пул WETH/WBTC/USDT.
5. В новой версии также ввели функцию автоматической концентрации ликвидности вокруг текущей цены. За счет этого пользователи смогли обменивать большие суммы с минимальным проскальзыванием.
6. Чтобы предложение было принято, в голосовании должно участвовать не менее 30% существующих veCRV, из которых не менее 51% должны его поддержать.
Инструменты: swaps, farming,
Governance: CRV token
1inch
1. DEX агрегатор.
2. Собирает цены на токены с различных бирж и предоставляет лучшую для обмена.
Инструменты: limit order, swap, farming, wallet
Governance: 1INCH token
dydx
1. DEX базирующаяся на Ethereum layer 2 system StarkWare (ZK).
2. создана для торговли perpetuals. Подобно опционам и фьючерсам, это позволяет спекулировать на будующей цене активов. Однако, в отличие от них же, perpetuals не имеют даты окончания срока действия.
3. dydx работает не как AMM, а по принципу стандартных orderbook.
Инструменты: ордера (perpetuals)
Governance: dydx token
Apollo dex
1. Является первой гибридной биржей CEX-DEX, но с ноября 2022 стала полностью DEX.
Инструменты: обмен и торговля деривативами, staking
Governance: apx token
Compound
1. Работает с переобеспеченными займами.
2. Если у вас есть Эфир на протоколе, то он конвертируется в cETH.
Инструменты: lending & borrowing
Governance: COMP token
Aave
1. Работает с переобеспеченными займами.
2. Предлагает пулы для активов off-chain: недвижимость, cargo and freight invoices.
3. В V3 версии появился Portal, который позволяет работать между сетями блокчейна.
Инструменты: lending & borrowing, flash loan
Governance: aave token
MakerDAO
1. Позволяет закладывать Эфир, чтобы получить токен DAI.
2. Своя система ликвидации и поддержания стабильной цены DAI.
3.В ноябре 2019 года сообщество проекта решило перейти к мультизалоговой системе — то есть позволить пользователям использовать для залога разные криптовалюты.
4. MakerDAO стал первым DeFi-протоколом, который стал принимать в залог акции публичных компаний.
5. Работает смарт-контракт под названием DAI Savings Rate (DSR) — это переменная ставка начислений от токенов DAI, заблокированных в смарт-контракте DSR.
6. Действует особый стабилизационный сбор (Stability Fee).
Инструменты: lending
Governance: mkr token
#dex #defi
🔥19❤3👍1
Отпуск на канале
В общем пару дней назад у меня появилась хорошая возможность уйти в отпуск и немного отдохнуть от аудитов и Solidity. Поначалу думал, что смогу делать посты в пути, но на деле, нахожусь постоянно в дороге.
Поэтому до 5 июня постов не будет. Единственное, может чуть позже сделаю ретроспективу постов и тем на канале, для более удобной навигации.
Всем приятного обучения и до скорой встречи!
#timeout
В общем пару дней назад у меня появилась хорошая возможность уйти в отпуск и немного отдохнуть от аудитов и Solidity. Поначалу думал, что смогу делать посты в пути, но на деле, нахожусь постоянно в дороге.
Поэтому до 5 июня постов не будет. Единственное, может чуть позже сделаю ретроспективу постов и тем на канале, для более удобной навигации.
Всем приятного обучения и до скорой встречи!
#timeout
❤22
Ретроспектива материалов на канале
Прошло практически 3 месяца с последнего сводного поста на канале. Теперь, на вопрос "Как стать Solidity разработчиком и аудитором?", можно смело отвечать: "Изучите все закрепы на канале!".
Итак, поехали:
Для разработчиков
The File Pattern
Storage Structs
Block scoping
Пример упаковки структур в маппинге
Один нюанс про библиотеки
Интересная библиотека SSTORE2
Необычная функция
Foundry
Foundry для продвинутых
Hardhat + Foundry
Шаблон для форка и тестов в Foundry
Foundry Safer Log
Аудит
Шаблон для аудиторского отчета
Ошибки в смарт контрактах
Странные ERC20
Немного о фантомных функциях
Аудит вне рамок (15 постов с тегом #outofbox)
Как проводить аудит в коопе
По следам аудита zkSync Era (3 поста)
Not So-Famous Solidity Attack Vectors
5 стадий обучения аудитора
Как читать аудиторские отчеты
DeFi
Сводный пост про биржи
Сводный пост про основные DeFi
Подготовка к собеседованиям
Подготовка к собеседованию в зарубежную компанию
Большая заметка по работе с памятью
Немного чисел EVM и Solidity
Сборник заметок по Solidity
Подборка статей для самообучения (2 поста)
Немного нового для общего развития
Уроки и другое
Новые задачи (5 штук)
Немного о EIP-1967
ERC2612, ERC20Permit, аппрув без газа, EIP712
ReentrancyGuard в прокси?
Больше о побитовых операциях
ERC4626: Tokenized vaults
Заметка по Access List и Transaction types
Приятного обучения! Как обычно, буду рад репостам.
#all
Прошло практически 3 месяца с последнего сводного поста на канале. Теперь, на вопрос "Как стать Solidity разработчиком и аудитором?", можно смело отвечать: "Изучите все закрепы на канале!".
Итак, поехали:
Для разработчиков
The File Pattern
Storage Structs
Block scoping
Пример упаковки структур в маппинге
Один нюанс про библиотеки
Интересная библиотека SSTORE2
Необычная функция
Foundry
Foundry для продвинутых
Hardhat + Foundry
Шаблон для форка и тестов в Foundry
Foundry Safer Log
Аудит
Шаблон для аудиторского отчета
Ошибки в смарт контрактах
Странные ERC20
Немного о фантомных функциях
Аудит вне рамок (15 постов с тегом #outofbox)
Как проводить аудит в коопе
По следам аудита zkSync Era (3 поста)
Not So-Famous Solidity Attack Vectors
5 стадий обучения аудитора
Как читать аудиторские отчеты
DeFi
Сводный пост про биржи
Сводный пост про основные DeFi
Подготовка к собеседованиям
Подготовка к собеседованию в зарубежную компанию
Большая заметка по работе с памятью
Немного чисел EVM и Solidity
Сборник заметок по Solidity
Подборка статей для самообучения (2 поста)
Немного нового для общего развития
Уроки и другое
Новые задачи (5 штук)
Немного о EIP-1967
ERC2612, ERC20Permit, аппрув без газа, EIP712
ReentrancyGuard в прокси?
Больше о побитовых операциях
ERC4626: Tokenized vaults
Заметка по Access List и Transaction types
Приятного обучения! Как обычно, буду рад репостам.
#all
👍20🔥8
Возвращаемся к работе и обучению
Фух, две активных недели отпуска пролетели, как один день. Это было весьма необычно для меня не думать о конкурсах или Solidity, учитывая то, что практически весь год я каждый день что-то читал, изучал или проводил аудит. А тут только еда, море, дорога, горы и солнце! В целом, голова разгрузилась и можно снова в бой.
Вчера я думал, как лучше организовать свою работу и участие в конкурсных аудитах. В том плане, что порой бывает сложно уследить за сроками их проведения и правильно распределить свое время.
Календари типа гугл или яндекса мне не совсем подходят, так как не дают мне общей картины загруженности. Jira, Trello и другие продукты Atlassian слишком нагруженные и больше подходят для нагруженных проектов и работы с командой.
По сути, мне просто нужен был сервис с формированием диаграммы Ганта. Выходом для меня стал проект ClickUp.
Хоть там и присутствуют дополнительные фичи, но отслеживание сроков конкурсов удобнее всего.
Более того, он бесплатный, если вы будете пользоваться им сами.
Другой крутой проект, который я решил использовать при проведении аудита - это Whim. Он позволяет создавать визуальные графики и майндкарты. Порой бывает полезно представить визуально, как функции взаимодействуют друг с другом или как перекликаются контракты.
В общем, понемногу вливаемся в рабочий ритм, строим планы и формируем базу для продвижения.
Всем приятной недели и легкого обучения!
#all
Фух, две активных недели отпуска пролетели, как один день. Это было весьма необычно для меня не думать о конкурсах или Solidity, учитывая то, что практически весь год я каждый день что-то читал, изучал или проводил аудит. А тут только еда, море, дорога, горы и солнце! В целом, голова разгрузилась и можно снова в бой.
Вчера я думал, как лучше организовать свою работу и участие в конкурсных аудитах. В том плане, что порой бывает сложно уследить за сроками их проведения и правильно распределить свое время.
Календари типа гугл или яндекса мне не совсем подходят, так как не дают мне общей картины загруженности. Jira, Trello и другие продукты Atlassian слишком нагруженные и больше подходят для нагруженных проектов и работы с командой.
По сути, мне просто нужен был сервис с формированием диаграммы Ганта. Выходом для меня стал проект ClickUp.
Хоть там и присутствуют дополнительные фичи, но отслеживание сроков конкурсов удобнее всего.
Более того, он бесплатный, если вы будете пользоваться им сами.
Другой крутой проект, который я решил использовать при проведении аудита - это Whim. Он позволяет создавать визуальные графики и майндкарты. Порой бывает полезно представить визуально, как функции взаимодействуют друг с другом или как перекликаются контракты.
В общем, понемногу вливаемся в рабочий ритм, строим планы и формируем базу для продвижения.
Всем приятной недели и легкого обучения!
#all
👍16❤🔥1