Аудитор, продавай свои баги
Написать этот пост меня сподвигла ситуация, которая происходила со мной на площадках 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
Необычный require и работа с ошибками
Иногда я писал про интересные моменты в коде, которые встречаю в процессе аудита. Вот и сейчас хочу поделиться одной очень занимательной реализацией кода.
В протоколе Unitas сформирована не совсем стандартная работа с отслеживанием возникающих ошибок в функциях по типу тех, что мы обычно пишем в require. Напомню, что условия для проверки пишутся так:
require(condition, "Error message...");
Можно создавать свои кастомные ошибки, типа "error Unauthorized();", но тогда нам придется использовать if/else вместо require.
В данном протоколе команда пошла дальше. Они создали отдельную библиотеку, где обозначили все возможные ошибки для своего проекта, и записали из в простые uint, например:
uint256 internal constant ADDRESS_ZERO = 1000;
1000 - это код ошибки, а само ее описание сделано комментарием выше.
Далее они написали свою реализацию функции require:
function _require(bool condition, uint256 errorCode) pure {
if (!condition) {
_revert(errorCode);
}
}
И свою реализацию функции revert. Она достаточно длинная, поэтому ее можно будет посмотреть по ссылке ниже на файл протокола.
Теперь в рабочих контрактах протокола можно использовать свой require для вывода ошибок:
_require(amount <= portfolio, Errors.AMOUNT_INVALID);
На самом деле, очень удобная система, когда все ошибки находятся в одном файле под своим кодом.
Саму реализацию файла можно посмотреть тут.
Надеюсь и вам понравится эта система так же, как и мне.
#error #require
Иногда я писал про интересные моменты в коде, которые встречаю в процессе аудита. Вот и сейчас хочу поделиться одной очень занимательной реализацией кода.
В протоколе Unitas сформирована не совсем стандартная работа с отслеживанием возникающих ошибок в функциях по типу тех, что мы обычно пишем в require. Напомню, что условия для проверки пишутся так:
require(condition, "Error message...");
Можно создавать свои кастомные ошибки, типа "error Unauthorized();", но тогда нам придется использовать if/else вместо require.
В данном протоколе команда пошла дальше. Они создали отдельную библиотеку, где обозначили все возможные ошибки для своего проекта, и записали из в простые uint, например:
uint256 internal constant ADDRESS_ZERO = 1000;
1000 - это код ошибки, а само ее описание сделано комментарием выше.
Далее они написали свою реализацию функции require:
function _require(bool condition, uint256 errorCode) pure {
if (!condition) {
_revert(errorCode);
}
}
И свою реализацию функции revert. Она достаточно длинная, поэтому ее можно будет посмотреть по ссылке ниже на файл протокола.
Теперь в рабочих контрактах протокола можно использовать свой require для вывода ошибок:
_require(amount <= portfolio, Errors.AMOUNT_INVALID);
На самом деле, очень удобная система, когда все ошибки находятся в одном файле под своим кодом.
Саму реализацию файла можно посмотреть тут.
Надеюсь и вам понравится эта система так же, как и мне.
#error #require
👍22
Новые видео от Патрика Коллинса
Возможно, вы пропустили, но тот самый Патрик Коллинс, который выпустил 32 часовой курс на ютуб по Solidity, пошел дальше и выпустил крутой 27 часовой курс по Foundry! Машина!
Также в этом посте хочу рассказать про другое его видео, посвященное созданию StableCoin. Примечательно то, что помимо написания самого контракта, в первой половине видео Патрик рассказывает теорию о том, что такое вообще это стейблы и как они ранжируются сегодня.
Курс по Foundry в трех видео
Первое, второе и третье.
Видео про стейблкоины
Уверен, теперь вы знаете, чем занять свой июнь!
Приятного обучения!
#stablecoin #foundry #patrick
Возможно, вы пропустили, но тот самый Патрик Коллинс, который выпустил 32 часовой курс на ютуб по Solidity, пошел дальше и выпустил крутой 27 часовой курс по Foundry! Машина!
Также в этом посте хочу рассказать про другое его видео, посвященное созданию StableCoin. Примечательно то, что помимо написания самого контракта, в первой половине видео Патрик рассказывает теорию о том, что такое вообще это стейблы и как они ранжируются сегодня.
Курс по Foundry в трех видео
Первое, второе и третье.
Видео про стейблкоины
Уверен, теперь вы знаете, чем занять свой июнь!
Приятного обучения!
#stablecoin #foundry #patrick
🔥11👍4❤1
Держим руку на пульсе
Давно не было материалов на канале. Начало лета выдалось какое-то слишком активное. Даже на конкурсные аудиты пока не получается выделять достаточно времени.
При этом на канале уже 878 участников! Это огромное количество для меня! Хочу узнать немного про ваш уровень и планы с Solidity.
Поэтому буду благодарен, если пройдете опрос ниже. Интересно, сколько у нас новичков:
Давно не было материалов на канале. Начало лета выдалось какое-то слишком активное. Даже на конкурсные аудиты пока не получается выделять достаточно времени.
При этом на канале уже 878 участников! Это огромное количество для меня! Хочу узнать немного про ваш уровень и планы с Solidity.
Поэтому буду благодарен, если пройдете опрос ниже. Интересно, сколько у нас новичков:
👍9